Objetivo
Proteger el flujo de publicación y consumo de imágenes
Enfoque
Registry, firmas, digest, procedencia y promoción
Resultado
Desplegar solo imágenes confiables y trazables
12.1 Introducción
Las imágenes de contenedores se construyen, almacenan, distribuyen y despliegan a través de registros. Ese registro puede ser un servicio cloud administrado, una solución interna o un registry público. En todos los casos, es una pieza crítica de la cadena de suministro.
Si alguien logra publicar una imagen maliciosa, sobrescribir un tag, robar credenciales del registry o desplegar una imagen sin verificar, el impacto puede llegar directamente a producción.
La seguridad del registry debe cubrir identidad, permisos, escaneo, firma, procedencia, retención, auditoría y políticas que impidan ejecutar imágenes no confiables.
12.2 Rol del registro de contenedores
Un registro de contenedores almacena imágenes y metadatos. Permite que pipelines publiquen artefactos y que entornos de ejecución los descarguen para desplegar aplicaciones.
Funciones típicas:
- Almacenar imágenes por repositorio, tag y digest.
- Controlar quién puede subir, leer, borrar o administrar imágenes.
- Escanear vulnerabilidades y generar reportes.
- Aplicar retención y limpieza de imágenes antiguas.
- Registrar eventos de publicación, descarga y eliminación.
- Integrarse con pipelines, clusters y políticas de despliegue.
El registry no es solo almacenamiento. Es un punto de control donde se decide qué artefactos pueden circular dentro de la organización.
12.3 Riesgos principales del registry
| Riesgo |
Impacto |
Control inicial |
| Publicación no autorizada |
Imagen maliciosa disponible para despliegue |
Permisos mínimos y publicación solo desde pipelines aprobados |
| Sobrescritura de tags |
Despliegue de contenido distinto al esperado |
Tags inmutables, digest y promoción controlada |
| Credenciales filtradas |
Lectura o modificación de artefactos |
Tokens temporales, MFA y rotación |
| Imágenes sin escaneo |
Vulnerabilidades conocidas llegan a runtime |
Escaneo obligatorio y gates de política |
| Descarga desde registries públicos |
Dependencia de artefactos no gobernados |
Allowlist de fuentes y mirrors internos |
12.4 Control de acceso
El registry debe usar mínimo privilegio. No todas las identidades necesitan publicar, borrar o administrar repositorios. Los permisos deben separarse por función y ambiente.
Roles recomendados:
- Lectura: clusters o runtimes que descargan imágenes aprobadas.
- Publicación: pipelines autorizados que suben artefactos construidos.
- Promoción: procesos que mueven imágenes entre ambientes.
- Administración: pocos operadores que gestionan repositorios y políticas.
- Auditoría: equipos que consultan eventos y reportes sin modificar imágenes.
Las credenciales usadas por pipelines y clusters deben ser temporales o rotadas con frecuencia. Las cuentas compartidas dificultan trazabilidad.
12.5 Tags, digest e inmutabilidad
Un tag es un alias legible para una imagen. Un digest identifica el contenido exacto. Como los tags pueden ser mutables, confiar solo en ellos puede permitir cambios inesperados.
| Referencia |
Ventaja |
Riesgo |
latest |
Simple para pruebas |
No reproducible y cambiante |
| Tag de versión |
Legible y útil para releases |
Puede sobrescribirse si no hay inmutabilidad |
| Digest |
Apunta al contenido exacto |
Menos legible y requiere gestión de actualización |
| Tag inmutable |
Evita reemplazos silenciosos |
Requiere estrategia para nuevas versiones |
12.6 Firma de imágenes
Firmar una imagen permite verificar que fue producida por una identidad confiable y que no fue alterada desde su firma. La firma aporta integridad y autenticidad al artefacto.
Una estrategia de firma debe definir:
- Qué imágenes deben firmarse.
- Quién o qué pipeline está autorizado a firmar.
- Dónde se almacenan firmas y certificados.
- Cómo se protegen claves o identidades de firma.
- Qué políticas verifican la firma antes del despliegue.
- Qué ocurre si la firma falta, es inválida o pertenece a una identidad no aprobada.
Firmar imágenes sin verificarlas en despliegue solo crea evidencia pasiva. El control real aparece cuando el entorno rechaza imágenes no firmadas o no confiables.
12.7 Procedencia de imágenes
La procedencia describe de dónde viene una imagen y cómo fue construida. Permite responder qué código, commit, pipeline, builder, dependencias y parámetros participaron en el artefacto final.
Información útil de procedencia:
- Repositorio y commit de origen.
- Pipeline o workflow que construyó la imagen.
- Identidad que ejecutó el build.
- Imagen base y digest utilizado.
- Fecha, entorno y parámetros de build.
- Resultados de pruebas, escaneo y firma.
- SBOM asociado al artefacto.
12.8 Promoción entre ambientes
Una práctica madura es construir una imagen una vez y promover el mismo artefacto entre desarrollo, staging y producción. Esto evita reconstruir con diferencias ocultas.
Modelo recomendado:
- El pipeline construye la imagen y la identifica por digest.
- La imagen se escanea y firma.
- Se despliega en desarrollo o pruebas.
- Si pasa validaciones, se promueve el mismo digest a staging.
- Producción usa el mismo artefacto aprobado, no una reconstrucción distinta.
La promoción debe registrar aprobaciones, evidencias y resultados de validación.
12.9 Políticas de admisión
Las políticas de admisión permiten bloquear despliegues que no cumplen condiciones. En Kubernetes, pueden aplicarse para exigir imágenes firmadas, registries aprobados, digest específico o ausencia de tags inseguros.
Ejemplos de política:
- Permitir solo imágenes de registries corporativos.
- Bloquear uso de
latest en producción.
- Exigir firma válida de una identidad aprobada.
- Exigir digest en workloads críticos.
- Bloquear imágenes con vulnerabilidades críticas sin excepción.
- Impedir despliegue si no existe SBOM o procedencia verificable.
12.10 Retención y limpieza
Los registries acumulan muchas imágenes con el tiempo. Sin política de retención, aumenta costo, ruido de escaneo y riesgo de que alguien despliegue artefactos obsoletos.
La retención debe considerar:
- Conservar releases productivos por el tiempo necesario para rollback.
- Eliminar imágenes temporales de branches antiguas.
- Bloquear borrado accidental de imágenes productivas activas.
- Mantener evidencia de firma, SBOM y escaneo para auditoría.
- Retirar imágenes con vulnerabilidades críticas que ya no se usan.
12.11 Auditoría del registry
El registry debe generar eventos útiles para investigación y cumplimiento. Publicar, borrar, descargar o cambiar políticas son acciones relevantes.
Eventos a registrar:
- Inicio de sesión y emisión de tokens.
- Push y pull de imágenes.
- Eliminación o sobrescritura de tags.
- Cambios en permisos y políticas.
- Resultados de escaneo y cambios de severidad.
- Firma, verificación y promoción de imágenes.
- Accesos desde ubicaciones o identidades anómalas.
12.12 Dependencia de registries públicos
Consumir imágenes directamente desde registries públicos puede introducir disponibilidad, integridad y confianza externa en el despliegue. Una imagen pública puede cambiar, desaparecer, ser rate-limited o contener componentes no aprobados.
Controles recomendados:
- Usar mirrors internos de imágenes base aprobadas.
- Fijar por digest las bases críticas.
- Escanear y firmar internamente imágenes de terceros antes de uso.
- Definir allowlist de registries y repositorios permitidos.
- Evitar pulls directos desde internet en producción.
12.13 Respuesta ante imagen comprometida
Si una imagen maliciosa o vulnerable fue publicada, la respuesta debe ser rápida y trazable.
- Identificar digest, tags, repositorios y ambientes afectados.
- Bloquear nuevas descargas o despliegues de la imagen.
- Revisar quién publicó la imagen y desde qué pipeline o credencial.
- Rotar credenciales del registry y del pipeline si corresponde.
- Retirar o marcar la imagen como no confiable.
- Reemplazar workloads en ejecución por una imagen corregida.
- Analizar logs para detectar ejecución o comportamiento anómalo.
- Corregir la causa: permisos, firma, admisión o fuente de build.
12.14 Errores frecuentes
- Permitir que desarrolladores publiquen manualmente imágenes productivas.
- Usar tags mutables sin digest ni firma.
- No separar permisos de lectura, publicación y administración.
- Firmar imágenes pero no verificar firmas antes del despliegue.
- Permitir pulls desde cualquier registry público.
- No auditar descargas o publicaciones.
- Acumular imágenes obsoletas sin retención.
- Reconstruir una imagen para producción en lugar de promover el artefacto probado.
La confianza en una imagen debe poder demostrarse: origen conocido, build trazable, escaneo aceptable, firma válida y despliegue verificado.
12.15 Lista de verificación
- ¿El registry usa permisos mínimos por rol y ambiente?
- ¿Solo pipelines aprobados pueden publicar imágenes?
- ¿Los tags productivos son inmutables o se despliega por digest?
- ¿Las imágenes se firman y la firma se verifica antes de desplegar?
- ¿Existe procedencia vinculada a commit, pipeline y builder?
- ¿Se bloquean registries no aprobados?
- ¿Hay retención y limpieza de imágenes obsoletas?
- ¿Los eventos de registry se auditan y centralizan?
12.16 Qué debes recordar de este tema
- El registry es un punto crítico de la cadena de suministro de contenedores.
- Tags mutables pueden romper reproducibilidad y facilitar reemplazos silenciosos.
- Las firmas aportan valor cuando se verifican en admisión o despliegue.
- La procedencia permite saber cómo y desde dónde se construyó una imagen.
- Promover el mismo digest entre ambientes es más confiable que reconstruir en cada etapa.
12.17 Conclusión
La seguridad de registros, firmas y procedencia permite controlar qué imágenes entran en la plataforma y con qué nivel de confianza. Sin estos controles, una imagen maliciosa o no autorizada puede convertirse en un despliegue legítimo.
En el próximo tema iniciaremos el bloque de Kubernetes: arquitectura, API server, etcd, RBAC y namespaces.