Todo lo que llevamos construido en este módulo protege el clúster en tiempo de ejecución. RBAC decide quién puede hacer qué (08-01). El securityContext limita lo que puede hacer un contenedor (08-02). Las políticas de admisión impiden desplegar algo que no cumpla las reglas (08-03). Y las políticas de red controlan qué habla con qué y qué puede salir (08-04).

Pero todo eso descansa sobre una suposición que nunca hemos cuestionado: que las imágenes que ejecutamos son las que creemos.

Y esa suposición es frágil. registry.rutasnorte.example/api-reservas:2.7.1 es una etiqueta, y una etiqueta se puede reasignar: la imagen que se descargó ayer puede no ser la de hoy. La imagen base sobre la que se construyó contiene cientos de paquetes que nadie ha revisado. Las dependencias se instalaron desde repositorios públicos durante la construcción. Y hoy por hoy, nada impide que alguien con acceso al registro suba una imagen modificada con el mismo nombre y que el clúster la ejecute sin rechistar, con todos nuestros securityContext perfectamente aplicados... a un contenedor que hace algo distinto de lo que creemos.

Esta lección se ocupa de la cadena de suministro de las imágenes: de dónde vienen, cómo se construyen, cómo se identifican sin ambigüedad, cómo se firman y cómo se consigue que el clúster rechace todo lo que no esté verificado.

Advertencia importante. La política de imágenes de una plataforma de producción debe diseñarla y revisarla un profesional de seguridad. Cuando las imágenes procesan datos personales —api-reservas, postgres-reservas e informes-ocupacion en Rutas Norte— el responsable de cumplimiento normativo debe conocer qué controles existen sobre el software que trata esos datos, porque una dependencia comprometida es una vía directa de acceso a ellos. El enfoque de esta lección es exclusivamente defensivo: entender dónde se puede envenenar una imagen para cerrar cada punto y detectar los intentos.

1. La cadena de suministro de una imagen
2. Construir imágenes mínimas
3. Usuario no root en el Dockerfile
4. Identificar la imagen sin ambigüedad: etiquetas y digests
5. imagePullPolicy y la trampa de la etiqueta reutilizada
6. El registro privado
7. Firma y verificación con Cosign
8. Verificar en el clúster con una política de admisión
9. SBOM y atestaciones de procedencia
10. Política de imágenes base y actualización periódica
11. La política completa de imágenes de Rutas Norte
12. Errores comunes y consejos
13. Ejercicios
14. Conclusión

Una imagen de contenedor no aparece de la nada. Es el resultado de una cadena de pasos, y cada eslabón es un punto donde se puede introducir algo indeseado.

Fíjate en que las defensas se refuerzan entre sí. El digest garantiza que descargas exactamente el contenido que esperas, pero no dice si ese contenido es bueno. La firma dice que alguien de confianza lo aprobó, pero no si contiene vulnerabilidades. El escaneo dice qué vulnerabilidades tiene, pero no si alguien lo modificó. Hacen falta todas.

Piensa en api-reservas. Es una aplicación Node.js con quizá 400 dependencias transitivas: paquetes que instala un paquete que instala un paquete que pediste tú. Cada una es código que se ejecutará con acceso a la conexión de postgres-reservas, es decir, con acceso a la tabla de clientes.

No hace falta ningún fallo del kernel ni ninguna escalada de privilegios. Una dependencia comprometida ya está dentro, con los permisos legítimos de la aplicación. Ni el securityContext más restrictivo lo impide, porque no está haciendo nada prohibido: está usando la conexión a la base de datos que la aplicación necesita.

Esa es la razón de ser de esta lección.

El principio es sencillo: lo que no está en la imagen no puede tener vulnerabilidades ni ser usado por nadie.

Una imagen basada en una distribución completa trae cientos de paquetes que tu aplicación no usa: compiladores, gestores de paquetes, curl, wget, un intérprete de órdenes completo, herramientas de red. Cada uno es superficie de ataque y una fuente potencial de alertas de vulnerabilidad que hay que gestionar.

Es la técnica fundamental: usar una imagen con herramientas para construir, y copiar solo el resultado a una imagen limpia.

Puntos a destacar:

• npm ci en lugar de npm install. ci instala exactamente lo que dice package-lock.json y falla si el fichero de bloqueo no está sincronizado. install puede resolver versiones distintas en cada construcción, lo que hace que dos construcciones del mismo código produzcan imágenes diferentes. Reproducibilidad y seguridad van de la mano.
• Copiar los manifiestos antes que el código. Aprovecha la caché de capas: mientras las dependencias no cambien, no se reinstalan.
• --omit=dev: las dependencias de desarrollo (marcos de pruebas, linters) no deben acabar en producción. Suelen ser la mitad del árbol.
• --chown en el COPY: los ficheros quedan con el propietario correcto sin necesidad de un RUN chown que duplicaría el tamaño de la capa.
• Etiquetas OCI: dejan rastro de dónde viene la imagen. Cuando dentro de un año alguien encuentre esta imagen en el registro, sabrá de qué repositorio salió.

Un detalle importante que se olvida constantemente: los secretos usados durante la construcción quedan en las capas aunque los borres después. Si haces RUN echo $TOKEN > /tmp/token && ... && rm /tmp/token, el token sigue estando en la capa intermedia y cualquiera que descargue la imagen puede extraerlo. La solución correcta es RUN --mount=type=secret, que monta el secreto durante la orden sin persistirlo:

Y con nginx, el caso de tienda-web:

Esta es la parte que los artículos entusiastas no cuentan. Con distroless o scratch:

No hay shell. Eso es exactamente lo que queremos desde el punto de vista de la seguridad —quien consiga ejecutar código no tiene herramientas— pero significa que las técnicas de diagnóstico habituales no funcionan.

La solución es la que vimos en 07-06: los contenedores efímeros.

El contenedor efímero trae las herramientas y, con --target, comparte el namespace de procesos del contenedor objetivo. Puedes inspeccionar el proceso, su sistema de ficheros a través de /proc/1/root y su red, sin que la imagen de producción contenga ni una sola utilidad.

Nota de seguridad importante: kubectl debug requiere el subrecurso pods/ephemeralcontainers, que en 08-01 clasificamos como de riesgo muy alto y no concedimos ni a soporte ni a desarrollo. Es una operación de plataforma. Y en 08-03 la política de registro obligatorio de Kyverno incluía ephemeralContainers precisamente para que nadie pudiera inyectar una imagen arbitraria por esta vía.

Un principio útil: scratch para binarios estáticos (Go, Rust), distroless para lenguajes con runtime (Node.js, Python, Java), alpine cuando necesites un poco de sistema operativo, y una distribución completa solo si tienes una razón concreta que puedas escribir.

En 08-02 configuramos runAsNonRoot: true y runAsUser en los manifiestos. Aquí hacemos lo mismo desde el otro lado: declarar el usuario en la imagen.

Parece redundante y no lo es. Se refuerzan mutuamente:

El caso más valioso es el segundo: si mañana alguien copia esta imagen a un manifiesto nuevo sin el securityContext completo, el USER del Dockerfile sigue protegiendo. Y en el otro sentido, runAsNonRoot: true en el manifiesto detecta si alguien reconstruyó la imagen sin el USER y rechaza el pod en lugar de arrancarlo como root en silencio.

Esto es crítico y ya lo adelantamos en 08-02:

Con un nombre, Kubernetes no puede verificar runAsNonRoot: true, porque para resolverlo tendría que leer el /etc/passwd de dentro de la imagen antes de arrancarla:

El pod no arranca. Un fallo desconcertante cuya causa está en el Dockerfile, no en el manifiesto.

En distroless no hay adduser. Las imágenes con el sufijo :nonroot ya traen el usuario 65532 creado, que es lo más cómodo. Para scratch, se copia un /etc/passwd fabricado en la etapa de construcción:

La imagen resultante contiene tres ficheros: el binario, los certificados y el /etc/passwd. Nada más. No hay shell que abrir, no hay curl que usar, no hay gestor de paquetes que instale nada. Es la superficie de ataque más pequeña posible.

Un detalle que sorprende: sin los certificados raíz, cualquier conexión HTTPS falla con un error de verificación de certificado. Es el problema más habitual al pasar a scratch.

Con distroless esto falla porque no hay id. La alternativa es inspeccionar los metadatos:

Y una comprobación automatizable para la canalización:

Esta es, probablemente, la parte con más consecuencias prácticas de la lección.

latest no significa "la última": es simplemente la etiqueta que se usa por defecto cuando no especificas ninguna. No hay ninguna garantía de que apunte a nada en concreto.

Los problemas, uno a uno:

Ese segundo punto es especialmente insidioso porque produce incidencias imposibles de diagnosticar: la mitad de las peticiones funcionan y la otra mitad no, según a qué réplica lleguen.

En 08-03 escribimos una ValidatingAdmissionPolicy que prohíbe latest a nivel de clúster. Esa política es la que convierte esta recomendación en una garantía.

El siguiente escalón es usar etiquetas que, por convención y por configuración del registro, nunca se reasignan:

Esquemas habituales:

La clave es la palabra inmutable: una vez publicada 2.7.1, esa etiqueta nunca se reasigna a otro contenido. Si hay que corregir algo, se publica 2.7.2. Muchos registros permiten aplicar esa regla del lado del servidor (apartado 6), y entonces deja de ser una convención para ser una garantía.

Incluso con etiquetas inmutables por convención, la etiqueta es un puntero mutable: si alguien con acceso al registro la reasigna, el clúster descargará otra cosa.

El digest es el hash SHA-256 del manifiesto de la imagen. Es criptográficamente inmutable: si el contenido cambia, el digest cambia. No se puede reasignar porque no es un nombre, es una huella del contenido.

La objeción práctica es evidente: un digest es ilegible. La solución es escribir ambos:

O, en la práctica moderna, dejar que una herramienta lo gestione. Kustomize (10-04) resuelve el digest automáticamente:

Y herramientas como Renovate o Dependabot actualizan los digests con una pull request cuando hay versiones nuevas, con lo que el cambio de imagen pasa por revisión de código como cualquier otro cambio. Ese es exactamente el objetivo.

Esa segunda orden es oro puro para investigar un incidente: te dice exactamente qué contenido se está ejecutando, no qué etiqueta se pidió. Si el digest no coincide con el que esperabas, tienes un problema que investigar urgentemente.

Una comprobación muy útil: verificar que todas las réplicas corren el mismo digest.

Dos líneas para dos contenedores. Si aparecieran tres líneas para api, hay réplicas con versiones distintas.

imagePullPolicy determina cuándo el kubelet descarga la imagen del registro.

Si no especificas imagePullPolicy:

Ese comportamiento tiene una lógica: con un digest, IfNotPresent es perfectamente seguro porque la copia local es necesariamente el contenido correcto (si el digest coincide, el contenido coincide).

Aquí está el escenario que hay que entender:

1. Se despliega api-reservas:2.7.1 con imagePullPolicy: IfNotPresent.
2. Los nodos A, B y C descargan la imagen y la guardan en caché.
3. Alguien reasigna la etiqueta 2.7.1 en el registro a un contenido distinto.
4. Un pod se recrea en el nodo D, que no tenía la imagen: descarga la nueva.
5. Los pods de A, B y C siguen ejecutando la antigua.

Resultado: réplicas del mismo Deployment ejecutando contenidos distintos, con el mismo nombre de imagen. Y ninguna herramienta de Kubernetes te lo va a decir: kubectl get pods muestra la misma imagen en todos.

Solo mirando el imageID (el digest efectivo) se ve la discrepancia. Por eso la comprobación del apartado anterior es tan valiosa.

Y por eso la solución de fondo es usar digests, no ajustar imagePullPolicy:

Fíjate en el matiz de la primera fila. Always no te protege de una etiqueta reasignada maliciosamente: te garantiza que todos los pods ejecutan el contenido nuevo, que es exactamente lo que quería quien la reasignó.

Ese último punto es un beneficio de seguridad real: con IfNotPresent, un nodo que ya tiene la imagen en caché la sigue usando aunque las credenciales del registro se hayan revocado.

Con digest, IfNotPresent es a la vez seguro y robusto. Es lo mejor de ambos mundos.

Excepción: en rutas-norte-dev, donde se itera rápido con etiquetas mutables, Always es razonable. Y un aviso de 08-02 que aplica aquí: en minikube con imágenes construidas localmente, Always hace que el kubelet intente descargar del registro y falle; ahí es donde Never o IfNotPresent tienen sentido.

En 08-03 escribimos la política de Kyverno que obliga a que toda imagen venga de registry.rutasnorte.example. El registro deja de ser una comodidad para ser el punto donde se aplican todos los controles.

Ya vimos los imagePullSecrets en 03-02. La mejora importante es declararlos en la ServiceAccount en lugar de en cada pod:

Ventajas de declararlo en la ServiceAccount:

• No hay que repetirlo en cada Deployment: se olvida menos.
• Cambiar las credenciales es un solo objeto.
• Se puede tener una ServiceAccount con acceso a un repositorio concreto del registro y otra con acceso a otro.

Y una advertencia de 08-01 que aplica directamente: este Secret contiene credenciales del registro. Quien tenga list sobre secrets en el namespace puede leerlas. En nuestro diseño, solo plataforma.

El principio es la separación entre publicar y descargar:

Los nodos de producción nunca deben tener credenciales de publicación. Si alguien compromete un nodo y el imagePullSecret permite publicar, puede subir imágenes envenenadas al registro del que se abastece toda la plataforma. Es una escalada de un nodo al clúster entero.

La mayoría de registros modernos permiten configurar que una etiqueta, una vez publicada, no se pueda reasignar:

Esto convierte "usamos etiquetas inmutables por convención" en una garantía técnica. Un intento de reasignar una etiqueta falla:

Sigue siendo recomendable usar digests, porque la inmutabilidad protege contra el error y contra la reasignación, pero un registro comprometido a nivel de almacenamiento podría burlarla. El digest lo verifica el propio cliente.

Rutas Norte usa postgres:16.4, redis:7.4-alpine y nginx-unprivileged. Todas son imágenes públicas excelentes, y aun así conviene copiarlas al registro propio:

Qué resuelve esto:

Ese último punto tiene un valor de inventario que se subestima: cuando aparezca una vulnerabilidad grave en una librería, la pregunta será "¿qué imágenes nuestras la contienen?", y tener todo en un registro propio hace que la respuesta sea una consulta en lugar de una investigación.

Hasta ahora hemos garantizado qué contenido se ejecuta (digest). Falta garantizar que ese contenido lo aprobó alguien de confianza.

Un digest te dice que la imagen no ha cambiado. No te dice si esa imagen la construyó tu canalización o alguien que robó las credenciales del registro. La firma criptográfica responde a esa pregunta: quién avala esta imagen.

Sigstore es un proyecto que hace la firma de artefactos software accesible. Cosign es su herramienta para firmar imágenes de contenedor.

Instalación:

El modelo clásico:

Firmar siempre por digest, nunca por etiqueta. Si firmas imagen:2.7.1, Cosign resuelve el digest en ese momento; pero si alguien reasigna la etiqueta después, la firma no corresponde al nuevo contenido y la verificación falla, que es lo correcto pero confuso. Firmar por digest deja claro qué se está avalando.

El problema del par de claves es dónde vive la clave privada. Si está en la canalización, quien comprometa la canalización puede firmar cualquier cosa. Se puede mitigar con un KMS:

Es el modelo que recomienda Sigstore y resuelve el problema de la custodia de claves.

Funciona así:

1. Cosign obtiene un token OIDC de un proveedor de identidad (la propia canalización, GitHub Actions, GitLab CI, Google, etc.).
2. Solicita a Fulcio (la autoridad certificadora de Sigstore) un certificado de corta duración, válido diez minutos, que vincula la identidad con una clave efímera.
3. Firma la imagen con esa clave.
4. Publica la firma y el certificado en Rekor, un registro público de transparencia, inmutable y solo de adición.
5. Descarta la clave privada.

Verificación por identidad, no por clave:

Lo que estás verificando no es "esta imagen la firmó la clave X", sino algo mucho más útil: "esta imagen la firmó la canalización del repositorio plataforma/* de git.rutasnorte.example".

Comparación:

Recomendación para Rutas Norte: sin claves con OIDC, usando el proveedor de identidad de la canalización. Es más seguro y elimina el trabajo de custodiar claves.

Nota sobre privacidad: el registro de transparencia público de Sigstore hace públicos los nombres de las imágenes firmadas. Si eso es un problema (revela nombres internos de proyectos), se puede desplegar una instancia privada de Fulcio y Rekor.

El orden importa: escanear antes de publicar. Publicar primero y escanear después significa que durante un rato hay una imagen vulnerable disponible para que alguien la despliegue.

Firmar en la canalización es la mitad del trabajo. Si el clúster acepta cualquier imagen, la firma es un adorno: quien pueda saltarse la canalización y publicar directamente en el registro despliega lo que quiera.

La verificación de firmas tiene que ocurrir en el clúster, en el control de admisión. Es la única forma de garantizar que absolutamente todo lo que se ejecuta ha pasado por el proceso.

Retomamos Kyverno de 08-03, ahora con verifyImages:

Aspectos clave del manifiesto:

• mutateDigest: true es lo más elegante de esta política. Kyverno verifica la firma, obtiene el digest y reescribe el manifiesto para que use el digest en lugar de la etiqueta. Resuelve automáticamente el problema del apartado 4: aunque el Deployment diga :2.7.1, el pod que se crea usa @sha256:..., el mismo que se verificó.
• required: true: si la imagen no encaja con ninguna regla de verificación, se rechaza. Sin esto, una imagen de un registro no contemplado pasaría sin verificar.
• useCache: true: sin caché, cada creación de pod consulta el registro de transparencia, lo que añade latencia y crea una dependencia externa en el camino crítico.
• webhookTimeoutSeconds: 30: la verificación puede tardar. Si el tiempo de espera se agota y failurePolicy es Fail, no se pueden crear pods.
• Dos reglas: nuestras imágenes se verifican por identidad OIDC; las públicas replicadas, con la clave del equipo de plataforma que las revisó y copió.

Pedimos una etiqueta y se está ejecutando un digest verificado. Exactamente lo que queríamos.

Sigstore tiene su propio controlador de admisión, especializado únicamente en esto:

Y se activa etiquetando el namespace, igual que el PSA:

Para Rutas Norte, Kyverno, porque ya lo tenemos de 08-03 y evita añadir otro webhook de admisión. El policy-controller tiene sentido si no quieres un motor de política general.

Esta política es de las que pueden parar la plataforma:

• Si Rekor no responde y no hay caché, la verificación falla.
• Si la identidad de la canalización cambia (se migra de proveedor de CI), todas las firmas nuevas dejan de validar.
• Si failurePolicy: Fail y Kyverno cae, no se puede crear ningún pod.

Mitigaciones obligatorias antes de poner Enforce:

1. Empezar con validationFailureAction: Audit durante semanas.
2. useCache: true siempre.
3. Kyverno con tres réplicas, PDB y anti-afinidad (08-03).
4. Un procedimiento documentado para desactivar la política en una emergencia, con quién puede hacerlo y cómo se registra.
5. Excluir kube-system y rutas-norte-sistema.

Un SBOM (Software Bill of Materials) es la lista completa de todo lo que hay dentro de una imagen: cada paquete del sistema, cada librería, cada dependencia transitiva, con su versión y su licencia.

Formatos estándar: SPDX (norma ISO) y CycloneDX (OWASP). Ambos valen; lo importante es tener uno.

Adjuntarlo a la imagen como atestación firmada:

Así el SBOM viaja con la imagen, firmado, y se puede recuperar en cualquier momento:

Este es el escenario que justifica todo el esfuerzo. Un martes cualquiera se publica una vulnerabilidad crítica en una librería de registro muy utilizada. La pregunta que toda la organización necesita responder en minutos, no en días, es:

¿Está esa librería en alguna de nuestras imágenes? ¿En cuáles? ¿Con qué versión? ¿Cuáles están en producción?

Sin SBOM, la respuesta implica descargar cada imagen, inspeccionarla, revisar los ficheros de dependencias de cada repositorio y esperar no haberse dejado nada. Días de trabajo, con incertidumbre al final.

Con SBOM:

Dos minutos. Y con certeza, no con esperanza.

SLSA (Supply-chain Levels for Software Artifacts) es un marco que define niveles de garantía sobre cómo se construyó un artefacto. Una atestación de procedencia responde a:

Los niveles de SLSA, resumidos:

Un objetivo razonable para una plataforma como Rutas Norte es L2: construcción automatizada en un servicio alojado, con procedencia firmada. L3 requiere un servicio de construcción con garantías fuertes de aislamiento, lo que suele implicar infraestructura específica.

Y la pieza que cierra el círculo: exigir la atestación en admisión.

Con esto, una imagen sin SBOM no se despliega en producción. La consecuencia práctica es que el inventario nunca se queda desactualizado, porque es imposible desplegar algo que no esté inventariado.

Una imagen construida hoy con node:22.7.0-alpine no tiene vulnerabilidades conocidas. Dentro de tres meses, esa misma imagen —sin que nadie la haya tocado— tendrá varias, porque se habrán publicado vulnerabilidades en paquetes que contiene.

Una imagen no se degrada: el mundo cambia a su alrededor.

Esto tiene una consecuencia que mucha gente no interioriza: si una imagen lleva seis meses en producción sin reconstruirse, acumula seis meses de vulnerabilidades sin parchear, aunque el código de la aplicación sea perfecto.

La solución es reconstruir con regularidad, aunque el código no cambie.

Esta es la parte del argumento que hay que saber defender ante quien pregunte "¿para qué reconstruir si no hemos cambiado nada?".

Ese último punto es el decisivo. Un procedimiento de reconstrucción que se ejecuta cada semana está probado. Uno que se ejecuta una vez al año, cuando hay una crisis, está sin probar exactamente cuando más importa.

Y herramientas que automatizan el seguimiento:

Reunimos todo en el documento que rige la plataforma.

Una imagen solo se despliega en producción si cumple todos estos requisitos, y cada uno lo verifica un mecanismo concreto:

Este manifiesto reúne el módulo entero: la ServiceAccount de 03-06 y 08-01, el securityContext de 08-02, el cumplimiento de restricted de 08-03, y la referencia por digest verificado de esta lección.

Usar latest en cualquier entorno que no sea un experimento local. Rompe los rollbacks, hace irreproducibles los despliegues y puede dejar réplicas con versiones distintas.

Usar etiquetas móviles como :2.7 o :16. Se reasignan en cada parche. Parecen versiones concretas y no lo son.

Creer que imagePullPolicy: Always protege de una etiqueta reasignada. Garantiza que todas las réplicas ejecuten el contenido nuevo, que es justo lo que buscaba quien la reasignó. La solución es el digest.

Declarar el USER por nombre en el Dockerfile. runAsNonRoot: true no puede verificarlo y el pod no arranca, con un error cuya causa está en otro fichero.

Dejar secretos en las capas de la imagen. Borrarlos en un RUN posterior no los quita de la capa anterior. Usa RUN --mount=type=secret.

Usar npm install en lugar de npm ci. Puede resolver versiones distintas en cada construcción, haciendo la imagen irreproducible.

Incluir dependencias de desarrollo en la imagen final. Marcos de pruebas y linters no pintan nada en producción y suelen ser la mitad del árbol de dependencias.

Pasar a distroless sin plan de depuración. No hay shell. Hay que dominar kubectl debug con contenedores efímeros antes de necesitarlo en una incidencia.

Olvidar los certificados raíz al usar scratch. Todas las conexiones HTTPS fallan con un error de verificación de certificado.

Firmar por etiqueta en lugar de por digest. Deja ambigüedad sobre qué contenido se avaló.

Guardar la clave privada de firma en la canalización. Quien comprometa la CI puede firmar cualquier cosa. Usa firma sin claves con OIDC, o un KMS.

Firmar en la canalización y no verificar en el clúster. La firma sin verificación es un adorno: quien pueda publicar directamente en el registro despliega lo que quiera.

Poner la política de verificación en Enforce desde el primer día. Puede parar la plataforma entera. Audit durante semanas, useCache: true, alta disponibilidad del motor y un procedimiento de emergencia documentado.

Escanear después de publicar. Durante ese intervalo hay una imagen vulnerable disponible para desplegar.

Dar credenciales de publicación a los nodos de producción. Un nodo comprometido puede envenenar el registro del que se abastece toda la plataforma.

No reconstruir las imágenes que no cambian. Acumulan meses de vulnerabilidades sin parchear. Reconstruye semanalmente.

Consejo de oro: la pregunta que debes poder responder en cualquier momento es "¿qué está corriendo exactamente en producción ahora mismo, quién lo aprobó y qué contiene?". Digest para el qué, firma para el quién, SBOM para el contenido. Si falta una de las tres, tienes un hueco.

Este es el Dockerfile actual de worker-notificaciones:

1. Enumera todos los problemas de seguridad y de calidad que tiene.
2. Reescríbelo con construcción multietapa, base mínima y usuario no root.
3. Escribe las órdenes que verificarían que la imagen resultante cumple los requisitos de la política de Rutas Norte.

El Deployment de tienda-web en producción usa:

1. Explica los tres riesgos concretos de esta configuración.
2. Escribe las órdenes para obtener el digest, verificar su firma e inspeccionar su SBOM.
3. Escribe el fragmento corregido del manifiesto.
4. ¿Cómo comprobarías que las tres réplicas están ejecutando el mismo contenido?

Rutas Norte incorpora pasarela-sms, un componente que envía avisos por SMS de cambios de horario. Se construye en un repositorio distinto (https://git.rutasnorte.example/comunicaciones/pasarela-sms) por un equipo distinto.

Escribe la regla de Kyverno que hay que añadir a la política verificar-firma-imagenes para que:

• Solo se acepten imágenes de registry.rutasnorte.example/rutasnorte/pasarela-sms*.
• Firmadas desde el repositorio comunicaciones/pasarela-sms (y no desde otro).
• Con SBOM adjunto que contenga al menos un paquete.
• Sustituyendo la etiqueta por el digest verificado.

Indica también cómo la desplegarías sin riesgo de bloquear despliegues legítimos, y qué comprobarías antes de pasarla a Enforce.

Solución 1

1. Problemas del Dockerfile original:

El problema 9 es sutil y muy real: con la forma shell, el PID 1 es el intérprete de órdenes, que no propaga SIGTERM al proceso de Node. Kubernetes espera el terminationGracePeriodSeconds completo y luego mata el pod con SIGKILL, cortando las notificaciones en curso.

2. Dockerfile reescrito:

Y el .dockerignore, que resuelve los problemas 4 y 5:

.env y .git en esa lista no son opcionales: COPY . . sin .dockerignore puede meter credenciales de desarrollo y todo el historial del repositorio dentro de la imagen, donde quedan para siempre.

3. Verificación:

De 412 paquetes en la versión original a 187: menos de la mitad de superficie que vigilar.

Solución 2

1. Los tres riesgos:

2. Órdenes:

Nota: la fecha dice 2026-07-28, hace nueve días. Dentro del margen de 30 días de la política, pero conviene tenerlo presente.

3. Manifiesto corregido:

Y con Kustomize (10-04), para no escribir el digest a mano en cada entorno:

4. Comprobar que las tres réplicas ejecutan lo mismo:

Y la versión que devuelve un único valor si todo está bien:

Un 1 significa que todas las réplicas ejecutan el mismo contenido. Cualquier número mayor es un incidente que hay que investigar de inmediato: significa que hay réplicas con contenidos distintos bajo el mismo nombre.

Solución 3

Decisiones a destacar:

• subject sin comodín. Escribir comunicaciones/* permitiría que cualquier repositorio de ese grupo firmase imágenes de pasarela-sms. Al fijar la ruta exacta, solo la canalización de ese repositorio concreto puede avalar estas imágenes. Es el mismo principio de mínimo privilegio de 08-01, aplicado a la firma.
• Regla separada, no ampliar la existente. Podríamos haber añadido comunicaciones/* al subject de la regla principal, pero eso permitiría que el equipo de comunicaciones firmase imágenes de api-reservas. Cada repositorio firma lo suyo.
• El patrón pasarela-sms* con asterisco cubre variantes como pasarela-sms-worker si el componente crece. Si se prefiere ser estricto, se quita el asterisco.

Despliegue sin riesgo:

Qué comprobar antes de Enforce:

El punto 7 merece énfasis. Una política de verificación de firmas en Enforce puede impedir cualquier despliegue si Rekor no responde o si la identidad de la canalización cambia. Debe existir un procedimiento escrito, con nombres, para desactivarla en minutos, y ese procedimiento debe haberse ensayado. Una medida de seguridad que puede paralizar la plataforma y no tiene salida de emergencia es un riesgo operativo, no una protección.

Hemos protegido la cadena de suministro de las imágenes de Rutas Norte:

• Una imagen se puede envenenar en cinco puntos: la imagen base, las dependencias, el proceso de construcción, el registro y la descarga. Cada uno necesita su defensa, y las defensas se refuerzan entre sí: el digest garantiza el contenido, la firma garantiza el aval, el SBOM garantiza el inventario.
• Imágenes mínimas con construcción multietapa: scratch para binarios estáticos, distroless para lenguajes con runtime, alpine cuando hace falta sistema operativo. El coste es la depuración, que se resuelve con contenedores efímeros (kubectl debug).
• Usuario no root numérico en el Dockerfile, que se refuerza con el runAsNonRoot del manifiesto (08-02): cada uno protege el hueco del otro.
• latest es inaceptable y las etiquetas móviles como :1.9 también. La etiqueta inmutable es aceptable; el digest es la única referencia criptográficamente reproducible.
• imagePullPolicy: Always no protege de una etiqueta reasignada: garantiza que todas las réplicas ejecuten el contenido nuevo. Con digest, IfNotPresent es seguro y no depende de que el registro responda.
• El registro privado es el punto de control único: imagePullSecrets en la ServiceAccount, separación estricta entre publicar y descargar, inmutabilidad de etiquetas del lado del servidor, y réplica de las imágenes públicas que se usan.
• Cosign firma las imágenes, preferiblemente sin claves con identidad OIDC, que elimina el problema de custodiar la clave privada y permite verificar quién y desde dónde firmó.
• Firmar no basta: hay que verificar en el clúster. La política de Kyverno con verifyImages y mutateDigest: true rechaza lo no firmado y sustituye la etiqueta por el digest verificado.
• El SBOM convierte "¿tenemos esa librería vulnerable?" en una consulta de dos minutos en lugar de días de investigación. Las atestaciones de procedencia (SLSA) responden a de dónde salió la imagen y quién la construyó.
• Reconstruir semanalmente es más barato que parchear con prisa: menos delta, menos riesgo, y sobre todo un procedimiento probado en lugar de uno que se estrena el día de la crisis.
• La política completa de Rutas Norte establece quién publica dónde y los once requisitos que debe cumplir una imagen para entrar en rutas-norte-pro, cada uno verificado por un mecanismo concreto.

La plataforma está ahora protegida en las cuatro dimensiones: quién puede hacer qué, qué puede hacer un contenedor, qué habla con qué, y qué se ejecuta exactamente.

Pero quedan dos preguntas sin respuesta, y son justo las que hace cualquier auditoría. La primera es "¿quién hizo qué?": si mañana descubrimos que el Secret con las credenciales de postgres-reservas fue leído, o que un Deployment desapareció, o que una ServiceAccount hizo algo raro a las tres de la madrugada, ahora mismo no tenemos forma de saberlo. Hemos puesto puertas, pero no llevamos registro de quién las cruza. La segunda es "¿qué agujeros tengo ahora mismo?": sabemos escanear una imagen antes de publicarla, pero las que llevan meses en producción acumulan vulnerabilidades nuevas cada semana, y nadie las está mirando.

La última lección del módulo, 08-06, Auditoría, Escaneo y Gestión de Vulnerabilidades, responde a las dos: el registro de auditoría del apiserver y cómo consultarlo para responder a preguntas concretas, el escaneo continuo con Trivy dentro y fuera del clúster, la evaluación frente a los estándares CIS con kube-bench, la detección en tiempo de ejecución con Falco integrada con el Alertmanager del módulo 7, y —lo que de verdad falta en la mayoría de equipos— la gestión de vulnerabilidades como proceso, con plazos, responsables y excepciones con fecha de caducidad.