El contexto de seguridad por namespace

Las etiquetas pod-security.kubernetes.io/<modo>=<nivel> se combinan: un namespace puede exigir un nivel con enforce y, al mismo tiempo, avisar o auditar contra otro más estricto. Los niveles son Privileged, Baseline y Restricted. Un pod que cumple el nivel exigido pero no el de aviso entra, y quien lo aplica recibe una advertencia con lo que le falta.

Esa combinación es la rampa de subida: se exige lo que ya se cumple y se avisa de lo siguiente.

Un namespace sin etiqueta enforce no rechaza nada, aunque lleve etiquetas de aviso y de auditoría: informa y deja pasar. Es la configuración que da sensación de control sin ejercerlo, y suele ser el entorno de producción porque «allí no se quiere romper nada».

Abre namespaces.txt. Hay un namespace sin ninguna etiqueta y otro que tiene etiquetas de aviso y de auditoría pero ninguna de exigencia.

El pipeline puede ensayar cada carga contra un nivel sin aplicarla: una aplicación en modo de simulación del servidor (--dry-run=server) devuelve las mismas advertencias que daría el clúster. El resumen del ensayo dice, por contenedor, qué requisitos del nivel incumple: runAsNonRoot, allowPrivilegeEscalation, las capacidades o el perfil seccomp.

Abre reportes/ensayo-restricted.txt. El portal de seguimiento tiene dos contenedores y solo uno incumple.

Antes de pasar un namespace a enforce, la pregunta práctica es cuántas cargas se rechazarían. Se cuentan cargas, no filas: una carga con un contenedor que incumple ya está en la lista, y una con varios cuenta una vez.

Pasar producción a enforce=restricted de golpe rechazaría las nuevas versiones de las cargas que hoy incumplen. La ruta ordenada es: dejar warn y audit activos, corregir las cargas hasta que el ensayo salga limpio, exigir primero baseline y subir a restricted cuando el ensayo no tenga incumplimientos.