- Puntos Clave
- Por qué es importante la firma de imágenes de contenedores
- Cómo funciona la firma de imágenes de contenedores
- Las principales herramientas de firma de contenedores
- Mejores prácticas para la firma de imágenes de contenedores
- La brecha empresarial: Gestión clave
- Cómo ayuda la consultoría de cifrado
- Preguntas frecuentes
- Integre la gestión de claves empresariales a la firma de sus contenedores.
La firma de imágenes de contenedor consiste en adjuntar una firma criptográfica a una imagen de contenedor para que cualquier persona que la descargue pueda verificar quién la publicó y confirmar que no ha sido modificada desde su creación. Se trata de una firma de código aplicada a las imágenes OCI que se ejecutan en Docker y Kubernetes.
La firma de imágenes de contenedor adjunta una firma digital a una imagen de Docker u OCI, vinculada al resumen de contenido de la imagen, de modo que un registro o clúster de Kubernetes pueda verificar el origen e integridad de la imagen antes de ejecutarla. La firma demuestra que la imagen proviene de su canalización de compilación y que no ha sido manipulada en el registro ni durante la transmisión. Las herramientas más comunes son Sigstore Cosign y Notary v2 (Notation), que almacenan las firmas como artefactos separados en el registro junto con la imagen.
Puntos Clave
- La firma de imágenes de contenedor adjunta una firma criptográfica a la imagen del contenedor, vinculada a su resumen de contenido, para que los consumidores puedan verificar quién la creó y que no ha sido modificada.
- La firma digital moderna no incrusta la firma dentro de la imagen. La firma se almacena como un artefacto separado en el registro OCI que hace referencia al resumen de la imagen.
- Las herramientas principales son Sigstore Cosign (fácil de usar para desarrolladores, compatible con firmas OIDC sin clave y firmas con clave) y Notary v2 / Notation (estandarizada, orientada a PKI y almacenes de confianza, preferida para entornos empresariales). Docker Content Trust (DCT) es el método anterior y se está dejando de usar en las imágenes oficiales de Docker.
- Firma siempre el resumen de la imagen (la referencia @sha256), nunca una etiqueta mutable como :latest, porque las etiquetas pueden redirigir a contenido diferente.
- La verificación se aplica en el despliegue a través de Kubernetes Los controladores de admisión bloquean las imágenes no firmadas o no confiables antes de que se ejecuten.
Por qué es importante la firma de imágenes de contenedores
Los contenedores son la unidad estándar para el despliegue de software moderno, y una imagen de contenedor pasa por muchas manos entre la compilación y la ejecución: un sistema de integración continua la compila, un registro la almacena, un orquestador la descarga y un nodo la ejecuta. En cualquiera de estos puntos, un atacante que pueda sustituir o modificar una imagen puede ejecutar su código dentro de su entorno. La firma de imágenes de contenedor elimina esta vulnerabilidad al hacer que cualquier manipulación sea detectable.
Este es el mismo problema de la cadena de suministro que hizo que el ataque a SolarWinds fuera tan devastador, pero aplicado a los contenedores. Una firma digital demuestra dos cosas que un registro por sí solo no puede: procedencia, es decir, que la imagen proviene realmente de su canalización, e integridad, es decir, que los bytes exactos que firmó son los mismos que se están ejecutando. Sin una firma digital, un registro solo le indica que existe una imagen, no que sea la que usted confía.
Cómo funciona la firma de imágenes de contenedores
La firma de contenedores sigue el mismo patrón de clave pública que cualquier firma de código , adaptado a la forma en que los registros de contenedores almacenan los datos.
- Construir y distribuir mediante resumen: Tu canalización crea la imagen y la sube a un registro. La imagen se identifica mediante un resumen de contenido inmutable (un hash SHA256 de su contenido), no solo mediante una etiqueta mutable.
- Firma el resumen: Una herramienta de firma aplica un hash al manifiesto de la imagen y lo firma con una clave privada, generando una firma vinculada a ese resumen exacto. Firmar el resumen, no la etiqueta, es fundamental, ya que las etiquetas pueden redirigirse posteriormente a contenido diferente.
- Almacenar la firma en el registro: La firma se carga en el mismo registro como un artefacto OCI independiente que hace referencia al resumen de la imagen. La firma reside junto a la imagen, no dentro de ella.
- Verificar antes de ejecutar: Durante el despliegue, un verificador obtiene la firma, la compara con la clave pública o identidad de confianza y confirma que el resumen coincide. Si la verificación falla, la imagen se rechaza.
Un detalle crucial: dado que la firma está vinculada al resumen criptográfico, protege el contenido exacto de la imagen. Si tan solo un byte de la imagen cambia, el resumen cambia y la firma deja de coincidir. Esto es lo que permite detectar cualquier manipulación.
Las principales herramientas de firma de contenedores
Existen tres enfoques predominantes, y saber cuál es cuál evita mucha confusión.
Firma conjunta de Sigstore
Cosign, parte del proyecto Sigstore de la Linux Foundation, es la herramienta de firma de contenedores más utilizada. Admite dos modos. La firma basada en clave utiliza una clave privada que usted administra, la cual puede estar en un archivo, un KMS en la nube o un HSM al que se accede a través de PKCS#11.
La firma sin clave utiliza certificados de corta duración emitidos por la autoridad de certificación Fulcio de Sigstore, basados en una identidad OIDC (como una cuenta de GitHub, Google o Microsoft). El evento de firma se registra en el registro público de transparencia de Rekor. Cosign almacena las firmas en el registro OCI junto con la imagen y se integra perfectamente con los sistemas de CI y el control de admisión de Kubernetes.
Notario v2 (Notación)
Notation es la interfaz de línea de comandos (CLI) de Notary v2, un proyecto de la CNCF. Se centra en un formato de firma estandarizado y un modelo de infraestructura de clave pública (PKI) y almacén de confianza, donde los administradores definen qué identidades firmantes son de confianza mediante una política de confianza. Este diseño resulta atractivo para las empresas que ya gestionan sus propias autoridades de certificación y desean una firma basada en especificaciones y con soporte del proveedor. Notation se recomienda en las guías de Kubernetes gestionado de Microsoft (AKS) y Amazon (EKS).
Docker Content Trust (versión anterior)
Docker Content Trust (DCT), basado en The Update Framework y lanzado en 2015, se convirtió en el proyecto Notary v1. Si bien es el mecanismo original de firma de contenedores, ahora está obsoleto. Docker ha anunciado que dejará de dar soporte a DCT para las imágenes oficiales de Docker y recomienda a los editores migrar a un sistema más reciente como Sigstore o Notation. Las plataformas de registro están siguiendo el mismo camino; por ejemplo, Harbor dejó de dar soporte a Notary v1 en la versión 2.9 y ahora utiliza Cosign o Notation. Las nuevas implementaciones no deberían estandarizarse en DCT.
| Modelo de confianza | Mejor ajuste | |
|---|---|---|
| Cosign (Sigstore) | OIDC sin clave mediante Fulcio y Rekor, o claves autogestionadas | Firma amigable para desarrolladores, CI/CD, código abierto, amplio soporte de registro. |
| Notación (Notario v2) | PKI y almacén de confianza, formato de firma estandarizado | Empresas con infraestructura de clave pública (PKI) existente; guía sobre AKS y EKS. |
| Docker Content Trust (Notario v1) | Claves basadas en TUF, por etiqueta | Solo legado; al estar jubilado, planifique la migración. |
Mejores prácticas para la firma de imágenes de contenedores
- Firma el resumen, no la etiqueta: Vincula las firmas al resumen SHA256 inmutable. Una etiqueta como :latest puede redirigirse a contenido diferente, por lo que firmar una etiqueta no demuestra prácticamente nada.
- Proteja las claves de firma en el hardware: Las claves de firma de larga duración deben residir en un HSM o en un KMS respaldado por hardware, no en el portátil de un desarrollador ni en el disco de un ejecutor de CI, para que un host de compilación comprometido no pueda robarlas.
- Exigir verificación en el momento de la admisión: Utilice un controlador de admisión o un motor de políticas de Kubernetes para bloquear las imágenes no firmadas o no confiables en el momento del despliegue, de modo que la firma no sea meramente una recomendación.
- Verificar la identidad, no solo la presencia: Comprueba que la imagen esté firmada por una identidad de confianza, no solo que exista alguna firma. Una firma generada con una clave desconocida no inspira confianza.
- Adjunte la procedencia y las listas de materiales (SBOM): Las herramientas modernas pueden adjuntar certificados de procedencia de construcción y un Lista de materiales del software al mismo resumen, reforzando la cadena de custodia.
- Centralizar las claves y realizar auditorías: Utilice un servicio de firma centralizado para que cada operación de firma esté autenticada, registrada y auditable, en lugar de estar dispersa entre equipos con sus propias claves.
La brecha empresarial: Gestión clave
Las herramientas de firma resuelven los aspectos mecánicos de la generación y verificación de una firma. Sin embargo, por sí solas no resuelven la gestión de claves empresariales. En la práctica, ahí radica el éxito o el fracaso de los programas de firma de contenedores.
Si las claves de firma se encuentran en las máquinas de los desarrolladores o en los servidores de integración continua, quedan expuestas precisamente a la vulnerabilidad de la cadena de suministro que la firma pretende evitar. Si cada equipo gestiona sus propias claves, no existe un registro centralizado de quién firmó qué, ni una política coherente, ni una forma sencilla de rotar o revocar las claves tras un incidente. La firma sin clave traslada la confianza a un proveedor de identidad y a un registro público de transparencia, lo que resulta adecuado para proyectos de código abierto, pero no satisface las necesidades de cumplimiento y privacidad de todas las empresas.
El requisito empresarial es mantener las claves de firma de contenedores en el hardware, controlar quién puede firmar y registrar cada operación, sin ralentizar a los desarrolladores.
Cómo ayuda la consultoría de cifrado
CodeSign Secure de Encryption Consulting lleva la gestión de claves empresariales a la firma de imágenes de contenedores. Mantiene las claves de firma en un HSM FIPS 140-2 de nivel 2 en lugar de en las máquinas de los desarrolladores o los ejecutores de CI, se integra con el flujo de trabajo de firma de contenedores para que las imágenes se firmen con claves protegidas por hardware y controla quién tiene permiso para firmar, registrando cada operación para fines de auditoría.
Dado que CodeSign Secure centraliza la firma digital en todos los tipos de artefactos, la misma plataforma que protege la firma de Windows, Java y firmware también gestiona las imágenes de contenedores, lo que proporciona a los equipos de seguridad una política y un registro de auditoría coherentes, en lugar de un proceso independiente y sin control para los contenedores. Cuenta con el respaldo de las prácticas certificadas ISO/IEC 27001:2022 y SOC 2.
Preguntas frecuentes
¿Qué es la firma de imágenes de contenedores?
La firma de imágenes de contenedor (OCI) adjunta una firma criptográfica a la imagen, permitiendo que cualquier usuario pueda verificar quién la publicó y confirmar que no ha sido modificada desde su creación. La firma se vincula al resumen del contenido de la imagen y se almacena en el registro como un artefacto independiente. Es el equivalente a la firma de código en el mundo de los contenedores y protege la cadena de suministro de software entre la compilación y la implementación.
¿Cuál es la diferencia entre Cosign, Notation y Docker Content Trust?
Cosign, parte de Sigstore, es una herramienta amigable para desarrolladores que admite tanto la firma OIDC sin clave como las claves autogestionadas, y se usa ampliamente en CI/CD. Notation, la interfaz de línea de comandos para Notary v2, es un proyecto de CNCF con un formato de firma estandarizado y un modelo de almacén de confianza PKI preferido por las empresas y recomendado para AKS y EKS. Docker Content Trust (Notary v1) es el mecanismo original basado en TUF de 2015; ahora es obsoleto y se está retirando para las imágenes oficiales de Docker.
¿Debo firmar la etiqueta de la imagen o el resumen?
Firma siempre el resumen, la referencia inmutable @sha256, nunca una etiqueta mutable como :latest. Las etiquetas son punteros que pueden redirigirse a contenido diferente en cualquier momento, por lo que una firma en una etiqueta no demuestra prácticamente nada sobre lo que realmente se ejecuta. Una firma vinculada al resumen protege los bytes exactos de la imagen: si algún byte cambia, el resumen cambia y la firma deja de ser válida, lo que permite detectar cualquier manipulación.
¿Sigue siendo recomendable Docker Content Trust?
No. Docker Content Trust (DCT), basado en Notary v1, es una tecnología obsoleta. Docker ha anunciado que dejará de dar soporte a DCT para las imágenes oficiales de Docker y recomienda a los editores que migren a una solución de firma y verificación más reciente, como Sigstore o Notation. Las plataformas de registro están siguiendo el mismo camino; por ejemplo, Harbor dejó de dar soporte a Notary v1 en la versión 2.9. Los usuarios actuales de DCT deberían planificar una migración, y las nuevas implementaciones deberían estandarizar el uso de Cosign o Notation.
¿Cómo se verifica una imagen de contenedor firmada durante su despliegue?
La verificación suele ser aplicada por un controlador de admisión o un motor de políticas de Kubernetes que intercepta las implementaciones de imágenes. Cuando se programa un pod, el controlador obtiene la firma de la imagen del registro, la compara con la clave pública o identidad de confianza y confirma que la firma coincide con el resumen de la imagen. Si la imagen no está firmada o está firmada por una identidad no confiable, el controlador la rechaza, de modo que solo se ejecutan imágenes verificadas en el clúster.
¿Dónde deben almacenarse las claves de firma de contenedores?
Las claves de firma de contenedores de larga duración deben almacenarse en un módulo de seguridad de hardware (HSM) o en un servicio de gestión de claves basado en hardware, no en portátiles de desarrolladores ni en discos de ejecutores de CI, que son precisamente los sistemas que un atacante atacaría. Almacenar las claves en hardware impide que un host de compilación comprometido extraiga la clave privada. Las empresas suelen utilizar un servicio de firma centralizado que guarda las claves en un HSM, controla quién puede firmar y genera un registro de auditoría de cada operación de firma.
Integre la gestión de claves empresariales a la firma de sus contenedores.
Las herramientas de firma generan firmas digitales. Los programas empresariales necesitan que estas firmas estén respaldadas por claves protegidas por hardware, políticas de seguridad aplicadas y un registro de auditoría completo. Descubra CodeSign Secure para firmar sus imágenes de contenedor con claves protegidas por HSM, políticas de seguridad centralizadas y auditoría, junto con el resto de sus herramientas de firma de código.
- Puntos Clave
- Por qué es importante la firma de imágenes de contenedores
- Cómo funciona la firma de imágenes de contenedores
- Las principales herramientas de firma de contenedores
- Mejores prácticas para la firma de imágenes de contenedores
- La brecha empresarial: Gestión clave
- Cómo ayuda la consultoría de cifrado
- Preguntas frecuentes
- Integre la gestión de claves empresariales a la firma de sus contenedores.
