Pod Security Standards: la checklist que paso antes de aprobar cualquier despliegue

Desde que Kubernetes eliminó las PodSecurityPolicies en la versión 1.25, el control nativo de qué puede hacer un pod se llama Pod Security Admission. Funciona con tres niveles (Pod Security Standards) que se aplican por namespace con una simple etiqueta. Es de lo más rentable que se puede activar en un cluster. Aun así, en muchos clusters que reviso sigue sin configurar o está en modo “solo avisar” desde hace años.

Los tres niveles, en una frase cada uno:

• privileged: sin restricciones. Solo para componentes de sistema que realmente lo necesitan.
• baseline: bloquea las escaladas de privilegios conocidas (contenedores privilegiados, hostNetwork, hostPID, hostPath…). Es el mínimo razonable para cualquier namespace.
• restricted: aplica las buenas prácticas de endurecimiento completas. Es el objetivo para las aplicaciones.

Y tres modos para aplicarlos:

• enforce rechaza el pod.
• audit lo deja pasar, pero lo registra en el audit log.
• warn lo deja pasar, pero devuelve un aviso a quien despliega.

El truco está en combinarlos. Así es como lo activo en un namespace existente sin romper nada:

apiVersion: v1
kind: Namespace
metadata:
  name: mi-app
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Con esto, hoy ya no entra nada peligroso (baseline en enforce), y cada despliegue te avisa de lo que le falta para llegar a restricted. Cuando dejan de salir avisos, subes el enforce a restricted.

La checklist que reviso en cada manifiesto antes de aprobarlo:

• ¿runAsNonRoot: true y un runAsUser distinto de 0?
• ¿allowPrivilegeEscalation: false?
• ¿capabilities.drop: ["ALL"], añadiendo solo las que haga falta y justificándolas?
• ¿seccompProfile.type: RuntimeDefault?
• ¿Nada de privileged, hostNetwork, hostPID, hostIPC ni volúmenes hostPath?
• ¿Sistema de ficheros raíz de solo lectura (readOnlyRootFilesystem: true) cuando la aplicación lo permite?

Si el equipo responde “sí” a todo, el pod pasa restricted sin problemas. Si alguna respuesta es “no, porque…”, ese “porque” tiene que quedar documentado.

Si usas OpenShift, hay un matiz. OpenShift tiene sus propias Security Context Constraints (SCC), que son anteriores y más granulares, y conviven con Pod Security Admission. OpenShift sincroniza automáticamente las etiquetas de PSA según las SCC que tienen disponibles las service accounts del namespace. Por eso los avisos que ves no siempre coinciden con lo que esperarías de Kubernetes “puro”. Antes de concluir que algo está mal, revisa qué SCC se le está asignando al pod (la anotación openshift.io/scc).

Activar Pod Security Admission cuesta tres etiquetas por namespace. No tenerlo activado significa que cualquiera con permiso para crear pods puede montar el sistema de ficheros del nodo.

¿En qué nivel tenéis vuestros namespaces de aplicación: baseline, restricted, o todavía ninguno?

Pod Security, SCC y el resto de controles de admisión los trato a fondo, con manifiestos listos para adaptar, en mi manual “Seguridad y monitorización en Kubernetes” (950 páginas, en español). [Descarga la muestra gratuita]([URL de la muestra]) · Consigue el manual completo