En la lección anterior endurecimos cada componente de Rutas Norte: tienda-web corre sin root con el sistema de ficheros en solo lectura, api-reservas no tiene ni una capacidad de Linux, postgres-reservas escribe en su volumen gracias a fsGroup y todos llevan seccompProfile: RuntimeDefault. El trabajo está hecho y verificado.

Y aun así, hay un agujero enorme: todo eso depende de que alguien se acuerde. Mañana un compañero añade un sidecar y olvida el drop: ["ALL"]. Un desarrollador copia un manifiesto de un blog que trae privileged: true porque "así funcionaba". Un operador de terceros se instala con un DaemonSet que monta / del nodo. Ninguna de esas cosas rompe nada visible, nadie recibe una alerta, y el endurecimiento que construimos con tanto cuidado deja de aplicarse en el punto exacto donde importa.

Esta lección da el salto que lo cambia todo: pasar de "cada equipo pone bien su securityContext" a "el clúster rechaza un pod que no lo tenga". Es la tercera puerta que vimos en 08-01, el control de admisión, y es la diferencia entre una norma escrita y una norma aplicada.

Advertencia importante. Las políticas de admisión son el mecanismo que hace cumplir el diseño de seguridad, y por eso mismo un error en ellas puede bloquear despliegues legítimos o, peor, dar una falsa sensación de protección. El conjunto de políticas de un clúster de producción debe diseñarlo y revisarlo un profesional de seguridad. Cuando las cargas afectadas tratan datos personales —postgres-reservas, api-reservas e informes-ocupacion en Rutas Norte— el responsable de cumplimiento normativo debe conocer y aprobar qué se exige y qué excepciones existen.

1. De la norma escrita a la norma aplicada
2. Contexto histórico: las PodSecurityPolicy y por qué desaparecieron
3. Los Pod Security Standards: privileged, baseline y restricted
4. Pod Security Admission: activarlo con etiquetas en el namespace
5. Aplicación progresiva en Rutas Norte
6. Cargas que legítimamente necesitan privilegios
7. Las limitaciones del Pod Security Admission
8. Motores de política general: Kyverno y OPA Gatekeeper
9. Políticas de Kyverno para Rutas Norte
10. ValidatingAdmissionPolicy: CEL nativo sin instalar nada
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

Recordemos el recorrido de una petición a la API de 08-01:

La diferencia con RBAC es fundamental y conviene tenerla clarísima:

Alguien de plataforma tiene permiso RBAC para crear pods en rutas-norte-pro. Eso no cambia. Lo que añadimos es que, aunque tenga permiso, el pod concreto que envía debe cumplir unas reglas.

Y hay una propiedad muy valiosa: el objeto rechazado nunca llega a etcd. No se crea y hay que borrarlo después; sencillamente no existe. La respuesta llega al instante a quien hizo el kubectl apply, con el motivo escrito.

Los mutantes se ejecutan antes que los validantes, lo cual tiene sentido: primero se completa el objeto, luego se comprueba el resultado final.

Si buscas información sobre este tema encontrarás muchísimo material sobre PodSecurityPolicy (PSP). Es importante que sepas qué eran, porque aparecen constantemente en documentación antigua, en respuestas de foros y en manifiestos heredados. Pero también que tengas muy claro esto:

Las PodSecurityPolicy quedaron obsoletas en Kubernetes 1.21 y se eliminaron por completo en 1.25. En un clúster 1.30 no existen. Si un tutorial te dice que crees una PodSecurityPolicy, ese tutorial tiene al menos cinco años.

Un recurso a nivel de clúster que describía qué se permitía en un pod: si podía ser privilegiado, qué usuarios podía usar, qué volúmenes, qué capacidades. Su forma se parecía a esto:

Conceptualmente la idea era buena. La implementación tenía tres problemas graves que resultaron insalvables.

Una PSP no se aplicaba a nadie por sí sola. Se "activaba" concediendo el verbo use sobre ella mediante RBAC, y —esto es lo raro— al sujeto que creaba el pod, que muchas veces no era la persona sino un controlador. Cuando un Deployment creaba pods, el sujeto relevante era la ServiceAccount del controlador de ReplicaSets, no el usuario que hizo el kubectl apply.

El resultado: nadie sabía con certeza qué política se le estaba aplicando a un pod concreto, y responder a "¿por qué se ha rechazado esto?" era un ejercicio de arqueología.

Si a un sujeto le aplicaban varias PSP —cosa habitual— Kubernetes elegía una según un algoritmo complicado: primero las que no mutaban el pod, y si todas mutaban, la primera por orden alfabético. El orden alfabético. Renombrar una política cambiaba qué política se aplicaba.

Las PSP no solo validaban: también modificaban el pod (rellenaban runAsUser, añadían fsGroup, quitaban capacidades). Eso significaba que el pod que se ejecutaba no era el que estaba en tu manifiesto, y que aplicar el mismo YAML en dos clústeres podía dar resultados distintos sin aviso alguno.

En la práctica, activar PSP en un clúster existente rompía casi todo, y como no había un modo "avísame pero no bloquees", el camino habitual era crear una PSP permisiva "temporal" que se quedaba para siempre. La conclusión de la comunidad fue clara: un mecanismo de seguridad que nadie consigue activar no protege a nadie.

El sustituto, el Pod Security Admission, se diseñó explícitamente para corregir cada uno de esos defectos:

La contrapartida es que el PSA es mucho menos flexible: solo tres perfiles, sin posibilidad de personalizarlos. Ese hueco lo cubren los motores de política del apartado 8.

Los Pod Security Standards (PSS) son tres perfiles definidos por el proyecto Kubernetes. No son un recurso ni un objeto: son una especificación, un acuerdo sobre qué significa "seguro" en tres niveles.

baseline permite añadir solo estas, que son las del conjunto por defecto y todas relativamente inocuas:

Lo que baseline prohíbe añadir es lo verdaderamente peligroso: NET_ADMIN, SYS_ADMIN, SYS_MODULE, SYS_PTRACE, BPF, NET_RAW...

restricted va mucho más allá: exige drop: ["ALL"] y solo permite volver a añadir NET_BIND_SERVICE. Es exactamente la excepción de la que hablamos en 08-02 y por eso decíamos que el puerto alto es preferible: con puerto 8080 no necesitas ni siquiera esa.

Fíjate en que están todos los que usa Rutas Norte —emptyDir para los directorios de escritura, persistentVolumeClaim para los datos de PostgreSQL, configMap y secret para la configuración— y no está hostPath. Es la formalización de la advertencia de 05-01.

Compáralo con el bloque de "consejo de oro" de 08-02: es prácticamente el mismo. Los Pod Security Standards no son otra cosa que la codificación oficial de lo que ya hicimos a mano. Todo lo de la lección anterior encaja ahora en una etiqueta.

Nota importante: restricted no exige readOnlyRootFilesystem. Es una omisión conocida (era demasiado disruptiva para muchas cargas) y una de las razones por las que un motor de política complementa al PSA.

El Pod Security Admission (PSA) es el controlador que aplica los Pod Security Standards. Va integrado en el apiserver desde 1.25: no hay que instalar nada, no hay ningún pod que mantener, no hay webhook que pueda caerse.

Se activa poniendo etiquetas en el Namespace:

La sintaxis de la etiqueta es:

Los tres son independientes y se pueden combinar. Ahí está la clave de la adopción gradual: puedes poner enforce: baseline (bloquea lo peor) junto con warn: restricted y audit: restricted (te avisa de lo que aún no cumple, sin bloquear).

Un detalle esencial sobre enforce:

enforce solo actúa sobre pods que se crean o actualizan. No afecta a los que ya están corriendo. Si activas enforce: restricted en un namespace con pods que no cumplen, esos pods siguen funcionando tan tranquilos... hasta que el Deployment cree uno nuevo, que fallará. Es un fallo diferido y desconcertante si no lo esperas.

Por eso warn y audit no bloquean pero sí evalúan objetos que crean pods (Deployments, StatefulSets, CronJobs), avisándote en el momento del apply. enforce, en cambio, solo evalúa el pod, no el Deployment. Volveremos sobre esto en el apartado 7.

Los Pod Security Standards evolucionan: en cada versión de Kubernetes se pueden añadir controles nuevos. Si no fijas la versión, el valor por defecto es latest, lo que significa que una actualización del clúster puede empezar a rechazar pods que antes se aceptaban, sin que nadie haya tocado nada.

Fija siempre la versión. Y cuando actualices el clúster, sube la etiqueta como un cambio explícito y revisado, con warn primero. Es la diferencia entre una actualización planificada y un incidente el lunes por la mañana.

Se puede indicar al apiserver un perfil por defecto para los namespaces que no lleven etiquetas, mediante AdmissionConfiguration:

Esto es muy potente porque cubre los namespaces futuros: si mañana alguien crea rutas-norte-experimentos sin etiquetas, arranca ya en baseline. Sin esta configuración, un namespace sin etiquetar equivale a privileged, es decir, sin ninguna restricción.

Requiere acceso al plano de control, así que en Kubernetes gestionado (10-06) puede no estar disponible; en ese caso, la alternativa es una política de Kyverno que exija las etiquetas en todo namespace nuevo (lo veremos en el apartado 9).

Lee bien esa salida: el Deployment se ha aplicado (configured), pero el aviso enumera exactamente los cuatro campos que faltan, contenedor por contenedor. Es la mejor documentación posible de qué hay que arreglar. Anota lo bien redactado que está el mensaje: cada línea te dice el campo, el contenedor y el valor esperado.

Nunca actives enforce: restricted de golpe en un namespace de producción. El camino correcto tiene cuatro fases y puede llevar semanas. Vamos a recorrerlo.

Aquí no se bloquea nada: el clúster sigue funcionando igual. Ahora hay que provocar la evaluación de todas las cargas existentes. Un truco muy útil es reaplicar los manifiestos sin cambios:

--dry-run=server envía el objeto al apiserver, que lo pasa por toda la cadena de admisión y devuelve el resultado sin guardarlo. Es la forma segura de evaluar la situación completa.

Y para ver lo que evalúa el modo audit, la fuente es el registro de auditoría del apiserver, con la anotación pod-security.kubernetes.io/audit-violations. Lo veremos en detalle en 08-06.

Una herramienta que ahorra mucho tiempo en esta fase:

También se puede consultar directamente qué namespaces están sin protección:

Los <none> en enforce son namespaces donde ahora mismo se puede desplegar cualquier cosa, incluido default. Esa tabla es una excelente diapositiva para una reunión de seguridad.

baseline bloquea lo verdaderamente peligroso —privilegiados, namespaces de host, hostPath— y casi ninguna aplicación normal lo incumple. Es un paso con muy poco riesgo y mucho valor.

Ahora, si alguien intenta desplegar un pod privilegiado:

Ese es el momento en el que el trabajo de 08-02 deja de depender de la memoria de nadie.

Antes de dar este paso, todos los componentes deben cumplir. Probemos primero con un manifiesto sin endurecer para ver el mensaje completo:

El mensaje es una lista de tareas. Corregimos:

En 08-02 dejamos readOnlyRootFilesystem: false en PostgreSQL como excepción documentada. Buena noticia: restricted no exige ese campo, así que ese punto no bloquea. Lo que sí exige es runAsNonRoot: true y drop: ["ALL"], que ya teníamos. postgres-reservas pasa restricted sin cambios.

Comprobémoslo antes de tocar el namespace:

Sin avisos. Perfecto.

Y aquí no hay nada que arreglar: el recolector necesita legítimamente leer /var/log del nodo y necesita ser root para hacerlo. Es el tema del siguiente apartado.

Que rutas-norte-pre sea igual de estricto que producción es innegociable: si en preproducción se permite lo que en producción no, la promoción falla justo en el peor momento. Ese es todo el sentido de tener un entorno intermedio.

rutas-norte-dev en baseline es una concesión deliberada: bloquea lo peligroso pero permite, por ejemplo, correr como root para probar algo. Con warn: restricted, el desarrollador ve en cada apply exactamente qué le faltará para promocionar. Es una decisión de equilibrio que hay que documentar.

Hay software que no puede cumplir restricted, y no por dejadez. El plugin CNI configura las interfaces de red del nodo. El driver CSI monta volúmenes en el sistema de ficheros del anfitrión. El recolector de logs lee /var/log. El agente de detección en tiempo de ejecución (Falco, que veremos en 08-06) observa llamadas al sistema.

La respuesta correcta no es relajar el perfil de rutas-norte-pro. Es aislar esas cargas.

Tres decisiones importantes en ese manifiesto:

1. audit y warn siguen en restricted. Aunque enforce sea privileged, cada pod que se salte el perfil deja rastro en el registro de auditoría. Así el namespace privilegiado no es un agujero negro: sabemos exactamente qué se ejecuta ahí y con qué privilegios.
2. La anotación de justificación. Un namespace con perfil privileged es una excepción de seguridad y debe estar documentada en el propio objeto, con quién la revisa y cuándo.
3. RBAC estricto encima. Recordando 08-01: quien puede crear pods aquí puede crear pods privilegiados. Solo plataforma debe tener permiso, y en 08-01 vimos que crear pods en un namespace equivale a poder usar cualquier ServiceAccount de ese namespace: otra razón para que las aplicaciones no vivan ahí.

Y el complemento imprescindible en RBAC:

El PSA admite exenciones globales por tres criterios:

Un aviso sobre usernames: exime al sujeto en todos los namespaces, no solo donde te interesa. Es un permiso muy amplio. La exención por namespace es más fácil de razonar y de auditar.

Y la advertencia general: cada exención es una excepción de seguridad. Debe tener justificación escrita, responsable, y una revisión periódica que confirme que sigue siendo necesaria. En Rutas Norte, la lista de exenciones se revisa cada trimestre junto con el RBAC.

El PSA es excelente en lo suyo, y lo suyo es bastante estrecho. Conocer sus límites evita confiar en él para cosas que no hace.

El PSA evalúa objetos Pod. Punto. No mira Services, ni Ingresses, ni PVCs, ni ConfigMaps, ni NetworkPolicies.

Esto tiene un efecto práctico incómodo con enforce:

El Deployment se crea correctamente, el ReplicaSet se crea, y es el ReplicaSet el que no consigue crear pods. Quien hizo el apply ve un éxito y tiene que ir a mirar los eventos para descubrir el problema.

Por eso warn es tan valioso: sí evalúa los objetos que crean pods y avisa en el momento del apply. Mantén siempre warn activo aunque tengas enforce, precisamente por este motivo.

Cosas que el PSA no puede exigir:

Esa lista es exactamente el hueco que cubren Kyverno y Gatekeeper.

No puedes crear un perfil "restricted pero permitiendo hostPath en solo lectura" ni "restricted más readOnlyRootFilesystem". Los perfiles los define el proyecto Kubernetes y son inmutables.

Es una virtud de diseño (evita el problema 3 de las PSP), pero significa que el PSA nunca te va a ayudar rellenando campos. Si quieres que a todo pod se le añada automáticamente seccompProfile: RuntimeDefault, necesitas un motor de política mutante.

La recomendación práctica: PSA siempre, como línea base que no puede fallar (está en el apiserver, no depende de ningún pod), y encima un motor de política para todo lo demás.

Un motor de política es un webhook de admisión: el apiserver le envía cada objeto y él responde si lo acepta, lo rechaza o lo modifica.

Esto trae una consideración operativa muy seria: el motor de política se convierte en una dependencia del apiserver. Si el webhook está configurado con failurePolicy: Fail y los pods del motor están caídos, nadie puede crear nada en el clúster. Se han caído clústeres enteros así.

Las mitigaciones habituales: varias réplicas del motor con anti-afinidad (06-05), un PodDisruptionBudget (09-05), y excluir kube-system de los webhooks para poder recuperar el clúster.

Recomendación para Rutas Norte: Kyverno. Las razones son concretas:

• El equipo ya escribe YAML todo el día. Aprender Rego sería una barrera real para que las políticas las escriban también los desarrolladores.
• La verificación de firmas con Cosign está integrada, y es justo lo que necesitaremos en 08-05.
• La capacidad de generar objetos permite, por ejemplo, crear automáticamente la NetworkPolicy deny-all de 04-06 en cada namespace nuevo.
• La mutación resuelve el "añade seccompProfile a todo" sin tocar cien manifiestos.

Gatekeeper es la mejor opción si la organización ya usa OPA para otras cosas (control de acceso en APIs, políticas en Terraform) y quiere un único lenguaje de políticas para todo.

Tres réplicas y un PDB: el motor de política es infraestructura crítica y hay que tratarla como tal.

Una política de Kyverno es un ClusterPolicy (todo el clúster) o Policy (un namespace) con una lista de reglas.

Esta es probablemente la política de más valor por línea escrita. Impide que se despliegue nada que no haya pasado por el registro de la empresa, donde en 08-05 y 08-06 pondremos el escaneo y la firma.

Desmenucemos el manifiesto:

• validationFailureAction: Enforce rechaza. La alternativa es Audit, que solo genera un informe. Igual que con el PSA, se empieza en Audit y se pasa a Enforce cuando ya no hay incumplimientos.
• background: true hace que Kyverno evalúe también los objetos que ya existen, produciendo PolicyReport. Sin esto solo verías los objetos nuevos.
• match.any.resources define el ámbito. Aquí, pods de los tres namespaces de Rutas Norte. kyverno, kube-system y rutas-norte-sistema quedan fuera porque usan imágenes de infraestructura externas.
• =(initContainers) y =(ephemeralContainers): el prefijo =() significa "si este campo existe, debe cumplir el patrón". Sin él, un pod sin initContainers fallaría la validación. No olvides los contenedores efímeros: son la vía de kubectl debug (07-06) y sin esta línea alguien podría inyectar una imagen arbitraria en un pod de producción.
• El mensaje aparece literalmente en la terminal de quien despliega. Escribirlo bien —qué falla, por qué, y qué hacer— ahorra muchísimas preguntas.

Probando:

En 02-07 definimos el esquema de etiquetas de Rutas Norte, y en el módulo 7 los cuadros de mando y las alertas dependen de él. Una carga sin app.kubernetes.io/part-of: rutas-norte es invisible para la monitorización.

Sintaxis de patrones de Kyverno que aparece aquí:

La segunda regla es un detalle que parece menor y no lo es: una etiqueta entorno: dev en un manifiesto copiado a producción hace que Alertmanager encamine las alertas al canal de desarrollo y nadie se entere de una caída real. La política lo impide.

Fíjate en que exigimos limits.memory pero no limits.cpu. Es deliberado y es una decisión discutida: limitar la CPU provoca estrangulamiento (throttling) que puede degradar la latencia de api-reservas sin que se vea claro por qué, mientras que no limitar la memoria puede tumbar el nodo. Es un buen ejemplo de política que codifica una decisión técnica del equipo; lo trataremos a fondo en 09-06.

Aquí brilla Kyverno frente al PSA:

Con +(), si el manifiesto ya define securityContext, Kyverno no lo toca; si no lo define, lo añade. Es una red de seguridad, no una sustitución del trabajo de 08-02: lo correcto sigue siendo declararlo explícitamente en el manifiesto, para que quien lo lea sepa qué se está ejecutando.

Una advertencia sobre mutar: es exactamente el problema 3 de las PodSecurityPolicy. Úsalo con moderación y solo para valores por defecto seguros, nunca para "arreglar" manifiestos incorrectos, porque entonces el YAML del repositorio deja de describir lo que corre.

Esto garantiza que ningún namespace de Rutas Norte pueda existir sin la denegación por defecto que construimos en 04-06. Y synchronize: true hace que, si alguien la borra, vuelva sola. Es una capacidad que Gatekeeper no tiene y que resuelve un problema real.

Esos informes son la lista de deberes pendientes y, con background: true, se mantienen al día solos. En 08-06 los convertiremos en evidencia para auditorías de cumplimiento.

Desde Kubernetes 1.30, la ValidatingAdmissionPolicy permite escribir reglas de admisión dentro del apiserver, sin webhook, usando expresiones CEL (Common Expression Language).

Ventajas frente a un motor externo:

Se compone de dos objetos: la política (qué se comprueba) y el binding (dónde se aplica).

Puntos a observar:

• validationActions cumple el mismo papel que los modos del PSA: [Warn, Audit] para probar, [Deny] cuando estás seguro. Se pueden combinar: [Deny, Audit].
• namespaceSelector aplica la política solo a los namespaces etiquetados como parte de Rutas Norte. Los de sistema quedan fuera.
• CEL tiene funciones muy legibles: all(), exists(), has(), endsWith(), contains(), matches() para expresiones regulares.
• Separar política y binding permite escribir la regla una vez y aplicarla con distinta severidad en distintos entornos: [Warn] en dev y [Deny] en pro, con dos bindings.

Prueba:

Las VAP pueden leer configuración de un recurso externo, lo que las hace reutilizables:

messageExpression construye el mensaje con los valores reales, algo que se agradece mucho al depurar.

Usa VAP para reglas sencillas sobre campos: prohibir latest, exigir una etiqueta, limitar un valor numérico, comprobar un prefijo. Son gratis en disponibilidad y no añaden ninguna pieza que mantener.

Usa Kyverno para lo que VAP no puede: verificar firmas de imágenes (08-05), generar objetos, mutar, o políticas que necesitan consultar otros recursos del clúster.

Y usa el PSA siempre como línea base de securityContext, porque está integrado y no puede fallar.

En Rutas Norte usamos los tres, en capas:

Buscar tutoriales de PodSecurityPolicy. Se eliminaron en 1.25. Si un recurso te habla de kind: PodSecurityPolicy, está desactualizado y probablemente todo lo demás también.

Activar enforce: restricted directamente en producción. Los pods existentes siguen corriendo, pero el primer reinicio o la primera actualización falla. Recorre siempre las fases: warn/audit, luego baseline, luego restricted.

No fijar -version en las etiquetas. Sin ella se usa latest y una actualización del clúster puede rechazar pods que antes pasaban. Fija la versión y súbela como cambio explícito.

Creer que enforce avisa al aplicar un Deployment. No: el PSA solo evalúa pods. El Deployment se crea y es el ReplicaSet el que falla, en un evento que hay que ir a buscar. Mantén siempre warn activo, que sí evalúa los objetos que crean pods.

Dejar namespaces sin etiquetar. Un namespace sin etiquetas de PSA equivale a privileged. Comprueba default y cualquier namespace creado a mano; configura el valor por defecto en el apiserver o exige las etiquetas con Kyverno.

Relajar el perfil de todo un namespace por una carga. Si el recolector de logs necesita hostPath, va a rutas-norte-sistema con perfil privileged, no se baja rutas-norte-pro a baseline.

Olvidar el RBAC del namespace privilegiado. Un namespace con perfil privileged donde desarrollo pueda crear pods es peor que no tener PSA: da una falsa sensación de seguridad. Y recuerda de 08-01 que crear pods ahí permite usar cualquier ServiceAccount de ese namespace.

Usar failurePolicy: Fail sin alta disponibilidad del motor. Si Kyverno cae, nadie puede crear nada. Tres réplicas, PDB y anti-afinidad como mínimo, y excluye kube-system.

Olvidar initContainers y ephemeralContainers en las políticas. Un initContainer con una imagen sin verificar se salta toda la política de registro. Los contenedores efímeros son la vía de kubectl debug.

Poner validationFailureAction: Enforce desde el primer día. Igual que con el PSA: primero Audit, mira los PolicyReport, arregla, y luego Enforce.

Abusar de la mutación. Si Kyverno "arregla" los manifiestos, el YAML del repositorio deja de describir lo que corre. Úsala solo para valores por defecto seguros.

Mensajes de error inútiles. El mensaje lo lee una persona que está intentando desplegar. Dile qué falla, por qué existe la regla y qué tiene que hacer. Un buen mensaje ahorra una interrupción al equipo de plataforma.

Consejo de oro: las políticas son código. Van en k8s/politicas/ del repositorio, se revisan en pull request, y se prueban en rutas-norte-dev antes de llegar a producción. Una política aplicada a mano en producción es exactamente el mismo problema que un RoleBinding aplicado a mano.

El equipo crea rutas-norte-analitica para desplegar un servicio de agregación de estadísticas de ocupación. Escribe:

1. El manifiesto del Namespace en la fase 1 (avisar sin bloquear) con la versión fijada.
2. La orden que evaluaría un manifiesto existente contra el perfil sin desplegarlo.
3. El manifiesto del Namespace en su estado final, dado que el servicio ya está endurecido.

Al desplegar un componente nuevo en rutas-norte-pro, que tiene enforce: restricted, obtienes:

El manifiesto original:

1. Enumera las cuatro violaciones y explica qué significa cada una.
2. Reescribe el manifiesto para que cumpla restricted, sabiendo que NET_RAW se añadió "por si acaso" y que el fichero de /etc/rutasnorte/horarios es en realidad un fichero de configuración estático.
3. ¿Qué habrías hecho si NET_RAW fuese realmente imprescindible?

En 03-06 establecimos que las cargas que no hablan con la API deben llevar automountServiceAccountToken: false. Escribe un ClusterPolicy de Kyverno que:

• Se aplique a Pods de rutas-norte-pre y rutas-norte-pro.
• Rechace los pods que no declaren automountServiceAccountToken explícitamente (ni a true ni a false), obligando a que sea una decisión consciente.
• Exceptúe los pods cuya ServiceAccount sea api-reservas o agente-inventario, que sí necesitan el token.
• Incluya un mensaje que explique qué hacer.

Indica también cómo lo desplegarías de forma segura.

Solución 1

1. Fase 1: avisar sin bloquear

La anotación con fecha objetivo evita que "temporal" se convierta en "permanente", que es como acaban casi todas las fases 1.

2. Evaluar sin desplegar

--dry-run=server pasa el objeto por toda la cadena de admisión —PSA, VAP y Kyverno incluidos— y devuelve el veredicto sin guardar nada. Es distinto de --dry-run=client, que solo valida el YAML localmente y no detectaría nada de esto.

3. Estado final

Se mantienen audit y warn aunque enforce ya bloquee: warn sigue evaluando los Deployments (que enforce no ve) y audit deja constancia en el registro de auditoría.

Solución 2

1. Las cuatro violaciones:

2. Manifiesto corregido:

Los cuatro cambios y su justificación:

1. NET_RAW eliminado. Era "por si acaso": permite crear sockets en bruto, lo que sirve para hacer ping y para inspeccionar tráfico. Un exportador de horarios no lo necesita. Si el proceso falla al arrancar, el log lo dirá y entonces investigaremos por qué; no se conceden capacidades preventivamente.
2. hostPath sustituido por un ConfigMap. El fichero era configuración estática, exactamente para lo que sirve un ConfigMap (03-01). Además de cumplir la política, esto gana: el fichero deja de depender de que alguien lo haya copiado a cada nodo, queda versionado en Git y es idéntico en los tres entornos. La corrección de la política ha mejorado el diseño, que es lo que suele ocurrir.
3. runAsNonRoot: true + runAsUser: 10005 declarados explícitamente.
4. seccompProfile: RuntimeDefault en el pod, heredado por el contenedor.

Extras que no exigía restricted pero sí las políticas de Kyverno del apartado 9: etiquetas del esquema, resources y automountServiceAccountToken: false. Y readOnlyRootFilesystem: true, que ninguna política exige pero es la línea base de 08-02.

3. Si NET_RAW fuese imprescindible:

El proceso sería este, en orden:

1. Cuestionar el requisito. ¿Por qué necesita sockets en bruto un exportador de horarios? En el 90 % de los casos hay una alternativa (una comprobación TCP en lugar de ICMP, por ejemplo).
2. Si es real, usar una biblioteca que no lo necesite o cambiar el diseño.
3. Si no hay alternativa, no relajar rutas-norte-pro. Se despliega en un namespace propio con enforce: baseline (que sí permite NET_RAW), con RBAC restringido, con justificación anotada, con revisión trimestral y con aprobación del profesional de seguridad.
4. Documentar la excepción en el registro de excepciones de seguridad, con fecha de caducidad. Volveremos a este registro en 08-06.

Lo que nunca se hace es bajar rutas-norte-pro a baseline: eso convierte una excepción de un componente en una excepción de toda la plataforma.

Solución 3

Notas sobre la solución:

• El patrón "false | true" obliga a que el campo exista con uno de esos dos valores. Si el campo no está, la validación falla, que es justo lo que pedía el enunciado: convertir una omisión en una decisión.
• exclude.any.resources.subjects permite exceptuar por ServiceAccount. Una alternativa más mantenible a largo plazo sería exceptuar por una etiqueta (seguridad.rutasnorte.example/usa-api: "true"), para no tener que editar la política cada vez que una carga nueva necesite la API.
• Es una política de gobierno, no de bloqueo de un ataque: su valor está en forzar que alguien piense en cada despliegue.

Despliegue seguro, en cuatro pasos:

Y la verificación final:

Una precaución adicional importante: antes de pasar a Enforce, comprueba que la política no bloquea a los controladores del sistema que crean pods en esos namespaces (el controlador de ReplicaSets, el de Jobs). Si un controlador crea pods sin el campo, tus despliegues dejarán de funcionar. Probarlo primero en rutas-norte-dev con Enforce durante unos días es la forma barata de descubrirlo.

Hemos convertido el endurecimiento de 08-02 en algo que el clúster hace cumplir por sí solo:

• El control de admisión es la tercera puerta: RBAC decide si tienes derecho a la operación, la admisión decide si el objeto es aceptable. El objeto rechazado nunca llega a etcd.
• Las PodSecurityPolicy son historia: obsoletas en 1.21, eliminadas en 1.25. Sus tres defectos —RBAC contraintuitivo, orden alfabético impredecible y mutación— explican el diseño de su sustituto.
• Los Pod Security Standards definen tres perfiles: privileged (sin restricciones), baseline (bloquea las escaladas conocidas) y restricted (el objetivo para toda aplicación), que es esencialmente la codificación oficial de lo que hicimos a mano en 08-02.
• El Pod Security Admission va integrado en el apiserver y se activa con etiquetas en el namespace, con tres modos —enforce, audit, warn— que permiten la adopción gradual. Fija siempre -version para que una actualización del clúster no rompa nada.
• La adopción correcta es por fases: warn+audit, luego enforce: baseline, luego enforce: restricted. Nunca de golpe en producción. Y rutas-norte-pre debe ser tan estricto como rutas-norte-pro.
• Las cargas que legítimamente necesitan privilegios —CNI, CSI, recolector de logs— van a un namespace aparte con perfil privileged, RBAC restringido y justificación anotada. Nunca se relaja el perfil de producción por una carga.
• El PSA tiene límites claros: solo mira el pod, no puede exigir etiquetas, límites de recursos ni registros de imágenes, y no muta.
• Ese hueco lo cubren Kyverno (YAML, muta, genera, verifica firmas: la elección de Rutas Norte) y OPA Gatekeeper (Rego, genérico más allá de Kubernetes), y las ValidatingAdmissionPolicy con CEL cubren las reglas sencillas sin instalar nada.
• Rutas Norte usa los tres en capas: PSA como base infalible, VAP para reglas simples, Kyverno para el registro obligatorio, las etiquetas del esquema, los límites de recursos y la generación automática de la NetworkPolicy deny-all.

Ahora el clúster rechaza por sí mismo un pod privilegiado, uno que monte hostPath, uno que corra como root o uno cuya imagen no venga del registro de la empresa. Nadie puede saltárselo por olvido.

Pero volvamos a mirar el conjunto. Hemos protegido quién puede hacer qué (08-01) y qué puede hacer un contenedor (08-02 y 08-03). Falta una dimensión entera: qué puede hablar con qué. En 04-06 pusimos una NetworkPolicy deny-all en rutas-norte-pro y autorizamos las conversaciones una a una, y ya entonces señalamos dos límites incómodos: las políticas trabajan en L3/L4 —no entienden de rutas HTTP ni de métodos— y no registran nada, así que un intento de conexión denegado es invisible. Además, dentro del clúster todo el tráfico viaja sin cifrar una vez pasado el TLS del Ingress: quien pueda observar la red del nodo ve las consultas a postgres-reservas en claro, con los datos personales incluidos. Y el tráfico saliente sigue prácticamente sin restringir, que es la vía natural por la que se exfiltra una base de datos de clientes.

La siguiente lección, 08-04, Seguridad de Red, construye la estrategia completa sobre lo que ya sabes: microsegmentación, control del tráfico de salida y el problema de las IP frente a los nombres de dominio, cifrado en tránsito con mTLS y mallas de servicio —Istio, Linkerd y Cilium comparadas, con el criterio honesto de cuándo hace falta una y cuándo no—, protección del perímetro y del plano de control, y la visibilidad del tráfico que es justo lo que le falta a NetworkPolicy.