La seguridad de container registry es la práctica de proteger el sistema que almacena y distribuye sus imágenes de contenedores, de modo que solo imágenes confiables y verificadas puedan entrar en él y solo cargas de trabajo autorizadas puedan hacer pull de él. Si la construcción de imágenes es donde se ensambla el software, el registry es donde este espera para ser distribuido, y eso lo convierte en uno de los objetivos de mayor apalancamiento de todo su pipeline. Cada cluster, cada nodo, cada job de CI que ejecuta un contenedor termina volviendo a un registry y haciendo pull. Comprometa ese único punto y comprometerá todo lo que está aguas abajo.
Este es el análisis en profundidad sobre registries dentro de nuestra guía más amplia sobre seguridad de Docker y contenedores. Si ya reforzó la forma en que las imágenes se construyen y configuran, el registry es el siguiente eslabón de la cadena, y merece el mismo escrutinio.
El registry como punto crítico de la cadena de suministro
Piense en lo que un registry realmente es: un almacén compartido y accesible por red de artefactos ejecutables al que muchos equipos hacen push y del que aún más cargas de trabajo hacen pull. Esa concentración es exactamente lo que lo vuelve peligroso. El OWASP Top 10 de 2025 elevó las fallas de la cadena de suministro de software a la posición A03 justamente porque los atacantes han aprendido que los puntos de distribución upstream les dan un radio de impacto enorme por un esfuerzo relativamente pequeño.
Algunos patrones de ataque específicos de los registries aparecen una y otra vez:
Imágenes envenenadas o con backdoor. Un atacante que obtiene acceso de push, o que introduce una capa maliciosa en un build, puede publicar una image que parece legítima pero que incorpora un criptominero, un reverse shell o código de recolección de credenciales. Como la image lleva un nombre y una tag familiares, nada aguas abajo la cuestiona.
Imágenes públicas con typosquatting. Los registries públicos alojan millones de imágenes, y nombres como alpine, alpin y a1pine son fáciles de confundir. Un desarrollador que copia una línea FROM bajo la presión de un plazo puede no notar nunca que una image base es una impostora.
Riesgos de pull-through y caché. Los cachés de proxy son maravillosos para la fiabilidad, pero un caché que replica ciegamente lo que sea que sirva un upstream también puede replicar fielmente un upstream comprometido. Si hace caché por tag mutable, puede terminar sirviendo una image intercambiada mucho después de que la original fuera descargada.
El tema que subyace a todo esto es la confianza. Un registry, por defecto, distribuye lo que sea que se le haya enviado, a quien sea que pregunte. La seguridad de registry es el trabajo de añadir cláusulas de "pero solo si" a esa oración.
Registries públicos frente a privados
La decisión estructural más eficaz que puede tomar es dejar de hacer pull directamente de registries públicos en producción. Los registries públicos como Docker Hub son indispensables para el descubrimiento y para el abastecimiento de imágenes base, pero son ecosistemas abiertos que usted no controla. Cualquiera puede publicar; las imágenes cambian; los límites de tasa y la disponibilidad no dependen de usted.
Un registry privado, o un proxy privado que hace pull-through hacia fuentes públicas, le da un límite controlado. Las imágenes base entran a través de un paso de evaluación, se escanean y aprueban, y luego se vuelven a publicar internamente como imágenes "golden" sobre las que sus equipos tienen permitido construir. Las cargas de trabajo hacen pull solo del registry interno, así que usted siempre sabe con exactitud qué se está distribuyendo y puede revocar una image defectuosa en un único lugar.
El paso de evaluación importa tanto como el límite. Antes de promover una image base pública hacia dentro, confirme su digest, revise lo que realmente contiene, prefiera variantes mínimas o distroless que carguen menos superficie de ataque, y fije (pin) a un digest en lugar de a una tag flotante, para que aquello que aprobó sea aquello que sigue recibiendo.
# Pin by immutable digest, not a mutable tag, when promoting a base image
docker pull alpine@sha256:
docker tag alpine@sha256: registry.internal.example.com/base/alpine:3.20-approved
docker push registry.internal.example.com/base/alpine:3.20-approved
Control de acceso: autenticación y autorización
Si el registry es un punto crítico, sus credenciales son las llaves de ese punto crítico. Trátelas en consecuencia.
Parta del mínimo privilegio. Los sistemas de CI y los agentes automatizados deben autenticarse como cuentas robot o de servicio dedicadas, cada una acotada exactamente a los repositorios que necesita y exactamente a los verbos que necesita. Un job de build que publica un servicio no necesita acceso de push a todos los repositorios, y casi nada fuera de un paso de promoción controlado necesita derechos de delete.
Prefiera tokens de corta duración antes que secretos estáticos de larga duración. Muchos registries permiten intercambiar una identidad de carga de trabajo o un token OIDC de su proveedor de CI por un token de registry acotado y con expiración, lo que significa que no hay una contraseña duradera reposando en una variable a la espera de filtrarse. Donde deba usar una credencial estática, almacénela en un gestor de secretos, rótela según un calendario y acótela de forma estrecha.
Dos antipatrones merecen ser nombrados y eliminados: las credenciales de admin compartidas que varias personas o pipelines usan en común (nadie puede saber quién hizo qué, y la rotación es una pesadilla), y los endpoints de registry expuestos a la internet abierta cuando solo necesitan servir a redes internas. Coloque el registry detrás de un endpoint privado o restrínjalo mediante política de red, ponga en allowlist los rangos de CIDR y las identidades que legítimamente lo alcanzan, y exija autenticación incluso para los pulls de imágenes privadas.
Firma y verificación en el pull y en el deploy
El control de acceso decide quién puede hacer push. La firma decide si usted puede confiar en lo que se envió, después del hecho y con independencia de cómo llegó allí. Una firma criptográfica vincula un digest de image a una identidad, de modo que un consumidor puede verificar que una image determinada fue producida por un firmante autorizado y no ha sido alterada desde entonces.
Ya sea que use content trust clásico, un enfoque OCI-native como Notation, o un flujo keyless al estilo cosign vinculado a la identidad de la carga de trabajo, la forma es la misma: los publicadores firman el digest en el momento del push, y los consumidores verifican la firma antes de ejecutar la image.
# Sign an image after pushing (cosign-style keyless example)
cosign sign registry.internal.example.com/team/api@sha256:
# Verify before deploy; fail closed if the signature is missing or invalid
cosign verify \
--certificate-identity-regexp '.*@example\.com' \
--certificate-oidc-issuer https://token.actions.example.com \
registry.internal.example.com/team/api@sha256:
La firma solo rinde frutos si la verificación se impone, y no es opcional. El lugar para imponerla es en el límite donde las imágenes se convierten en cargas de trabajo en ejecución. En Kubernetes, un admission controller puede rechazar cualquier pod cuya image no esté firmada o falle la verificación, lo que convierte "firmamos nuestras imágenes" en "las imágenes no firmadas no pueden ejecutarse aquí". Esa imposición en el momento del admission es lo bastante importante como para que la abordemos por sí sola en seguridad de imágenes de Kubernetes.
Escaneo de imágenes en el registry
El escaneo en CI detecta problemas antes de que una image se publique, y usted absolutamente debe hacerlo. Pero el escaneo en CI es una instantánea tomada en el momento del build, y el panorama de vulnerabilidades no se queda quieto. Una CVE divulgada al día siguiente de su build recae sobre una image que su pipeline ya declaró limpia.
El escaneo en el registry resuelve la parte que el CI no puede. Como el registry contiene toda image que podría descargarse, es el lugar adecuado para hacer dos cosas:
Gate en el push. Escanee las imágenes a medida que llegan y bloquee o ponga en cuarentena cualquiera que cargue vulnerabilidades críticas o de alta severidad, para que una image reprobada nunca quede disponible para pull en primer lugar.
Reescanee de forma continua. Reevalúe las imágenes almacenadas contra datos de vulnerabilidad actualizados según un calendario, de modo que cuando surja una nueva CVE, las tags afectadas se señalen, se pongan en cuarentena o se bloqueen para pulls posteriores, aunque nada de la image haya cambiado.
Juntos, el gating y el reescaneo continuo significan que el conjunto de imágenes que sus cargas de trabajo pueden descargar siempre se juzga frente a lo que se sabe hoy, no a lo que se sabía el día del build.
Immutable tags, retención y garbage collection
Las tags mutables son una fuente silenciosa de riesgo para la cadena de suministro. Si :latest o :v2 pueden sobrescribirse, entonces la image que verificó ayer puede no ser la image que descarga hoy, y su rastro de auditoría se disuelve.
Configure los repositorios de modo que, una vez que una tag se envía, no pueda sobrescribirse. Las immutable tags garantizan que un nombre siempre se refiera al mismo contenido, lo que hace que las firmas, los resultados de escaneo y la provenance sean significativos a lo largo del tiempo. Los consumidores que fijan por digest obtienen la misma garantía de forma gratuita.
La inmutabilidad hace que los registries crezcan, así que combínela con una política de ciclo de vida. Las reglas de retención deben conservar lo que necesita para rollback y cumplimiento, a la vez que hacen expirar las imágenes antiguas, sin tag y sustituidas, y la garbage collection debe entonces recuperar el almacenamiento que esos manifests expirados y blobs huérfanos estaban ocupando. Un registry ordenado también es más fácil de razonar y más barato de reescanear.
Provenance, attestations y SBOMs
Una firma le dice que una image es auténtica. La provenance le dice de dónde vino y cómo se hizo. Almacenar attestations de provenance de build junto a la image, siguiendo un framework como SLSA, permite a un consumidor verificar qué pipeline construyó el artefacto, a partir de qué revisión de código fuente y con qué insumos.
Almacene también una software bill of materials junto a cada image. Un SBOM enumera los componentes dentro de la image, y cuando reside en el registry al lado del artefacto que describe, sus scanners y motores de políticas pueden responder "¿cuáles de mis imágenes contienen este componente recién vulnerable?" en segundos, en lugar de en una tarde frenética. Aquí es donde la higiene de registry se encuentra con el análisis de composición de software: el SBOM es el artefacto compartido del que dependen ambas disciplinas.
Secretos: manténgalos fuera de las imágenes y proteja las credenciales del registry
Dos fallas en el manejo de secretos se agrupan en torno a los registries. La primera es incrustar secretos en las imágenes. Los secretos de build, las claves de nube y los tokens copiados a una capa no desaparecen cuando una capa posterior los elimina, y una vez que esa image reside en un registry, cualquiera que pueda hacer pull de ella puede desenterrarlos. Use secret mounts de build-time que no persisten, y referencie los secretos de runtime desde un gestor de secretos en lugar de incrustarlos.
La segunda es el mal manejo de las propias credenciales del registry. El pull secret que un cluster usa para autenticarse en el registry es en sí mismo sensible; acótelo a solo pull, almacénelo como un secreto gestionado en lugar de en manifests en texto plano, y rótelo. Una credencial de pull de solo lectura que se filtra es mucho menos dañina que una con capacidad de push.
Auditoría y logging
Por último, haga que el registry sea observable. Registre cada push, pull, mutación de tag y cambio de permiso, envíe esos registros a su monitoreo central y alerte sobre los patrones que señalan problemas: un push desde una identidad inesperada, un pull de una image en cuarentena, un pico repentino de pulls de una tag antigua, una tormenta de fallas de autenticación. Los buenos registros convierten un incidente de misterio en una línea de tiempo, y a menudo son lo que le indica que una clave de firma o una credencial robot ha sido abusada antes de que se cause un daño real.
Cómo ayuda Rainforest
Proteger un registry es un trabajo por capas, y Rainforest está construido para cubrir esas capas sin pedirle que ensamble una docena de herramientas puntuales. Nuestra plataforma escanea las imágenes en busca de vulnerabilidades y configuraciones incorrectas dondequiera que residan, genera y rastrea SBOMs para que usted siempre sepa qué hay dentro de sus artefactos, y le permite definir e imponer políticas —como bloquear elementos críticos o exigir una firma válida— como un gate consistente a lo largo de su pipeline y su registry. Como el reescaneo es continuo, una image que estaba limpia en el momento del build se vuelve a juzgar a medida que surgen nuevas CVE, y las imágenes afectadas salen a la luz antes de llegar a producción. Puede ver cómo esto encaja en un programa más amplio en nuestra página de seguridad de contenedores.
Si desea ver el escaneo de registry y la imposición de políticas funcionando contra sus propias imágenes, agende una demostración y la recorreremos juntos.
