Perfiles privileged, baseline y restricted

Los Pod Security Standards definen tres perfiles. Privileged no restringe nada: es el perfil de los componentes que necesitan operar sobre el nodo. Baseline impide las escaladas de privilegios conocidas: prohíbe los contenedores privilegiados, los espacios de nombres del nodo (hostNetwork, hostPID, hostIPC), los volúmenes hostPath, los puertos del nodo y las capacidades de Linux añadidas fuera de una lista corta. Restricted sigue las buenas prácticas de endurecimiento actuales y parte de baseline: añade, entre otras cosas, ejecutar sin ser root, prohibir la escalada de privilegios, exigir un perfil seccomp y descartar todas las capacidades.

La consecuencia práctica es de inclusión: lo que cumple un perfil estricto cumple los más laxos.

Un campo como hostNetwork: yes hace que el pod comparta la red del nodo: ve sus interfaces y puede escuchar en sus puertos. Baseline lo prohíbe porque rompe el aislamiento de red del pod. En el extracto de manifiestos, cada pod declara sus campos de seguridad; leer el nivel que soporta es leer esos campos, no adivinar por el nombre.

Abre el inventario de pods y busca el que comparte la red del nodo.

Para cumplir restricted, un pod debe cumplir antes baseline y, además, declarar runAsNonRoot: true, allowPrivilegeEscalation: false, un perfil seccomp RuntimeDefault o Localhost, y descartar todas las capacidades (drop ALL), con la posibilidad de añadir solo una: la que permite abrir puertos por debajo del 1024. Un campo «(no definido)» no basta: restricted exige que esté declarado.

Revisa los siete pods y aplica ambas capas: primero baseline y después lo que añade restricted.

Baseline no prohíbe toda capacidad añadida: permite una lista corta (por ejemplo, cambiar propietario de archivos o abrir puertos bajos) y rechaza el resto. Un pod puede parecer impecable —sin root, con seccomp, con drop ALL— y aun así fallar baseline por una sola capacidad añadida que no está en esa lista.

Uno de los pods de sistema está en ese caso. Mira sus campos de capacidades.

La propuesta del martes es poner enforce=restricted en tienda y en sistema el lunes. Con lo que leíste, en sistema hay un pod privilegiado, uno con red del nodo y uno con una capacidad fuera de la lista; en tienda hay uno que cumple baseline pero no restricted. Exigir un nivel que los pods existentes no cumplen no los corrige: hace que dejen de poder crearse de nuevo.