Cada vez que descargas una imagen container y la despliegas en producci\u00f3n, est\u00e1s depositando una confianza impl\u00edcita en ese artefacto. Pero, \u00bfc\u00f3mo verificas<\/em> que la imagen no ha sido manipulada? \u00bfC\u00f3mo confirmas que fue realmente construida por tu pipeline CI\/CD y no inyectada por un atacante que comprometi\u00f3 tu registro?<\/p>\n La firma de im\u00e1genes container resuelve este problema adjuntando una firma criptogr\u00e1fica a tus im\u00e1genes. Antes del despliegue, tu orquestador o controlador de admisi\u00f3n puede verificar esa firma, asegurando que solo im\u00e1genes confiables y autenticadas entren en tu entorno. Este es un pilar fundamental de la seguridad de la cadena de suministro de software<\/strong> y un requisito en marcos como SLSA<\/a> y NIST SSDF<\/a>.<\/p>\n Pero las herramientas de firma no son todas iguales. Los tres enfoques dominantes hoy \u2014 Cosign<\/strong> (parte del proyecto Sigstore), Notation<\/strong> (el cliente de Notary v2) y GPG<\/strong> (el enfoque tradicional) \u2014 cada uno viene con compensaciones radicalmente diferentes en gesti\u00f3n de claves, integraci\u00f3n CI\/CD y compatibilidad del ecosistema.<\/p>\n En esta gu\u00eda, haremos una comparaci\u00f3n profunda y pr\u00e1ctica de los tres para que puedas tomar la decisi\u00f3n correcta para tus pipelines.<\/p>\n Cosign es la herramienta de firma de im\u00e1genes container del proyecto Sigstore<\/a>, que ahora es un proyecto graduado bajo la Linux Foundation. La misi\u00f3n de Sigstore es hacer que la firma de software sea ubicua eliminando la mayor barrera: la gesti\u00f3n de claves<\/strong>.<\/p>\n Cosign almacena las firmas como artefactos OCI directamente junto a la imagen firmada en el mismo registro. Esto significa que no hay un sistema separado de almacenamiento de firmas que mantener \u2014 tu registro de contenedores existente (Docker Hub, GitHub Container Registry, AWS ECR, Google Artifact Registry, etc.) cumple doble funci\u00f3n.<\/p>\n La caracter\u00edstica m\u00e1s revolucionaria de Cosign es la firma keyless<\/strong>. En lugar de gestionar claves de firma de larga duraci\u00f3n, Cosign se integra con dos servicios:<\/p>\n Con la firma keyless, el flujo de trabajo se ve as\u00ed:<\/p>\n Esto elimina toda la clase de problemas relacionados con la rotaci\u00f3n de claves, el almacenamiento de claves y el compromiso de claves. No hay ning\u00fan secreto de larga duraci\u00f3n que proteger.<\/p>\n Cosign tambi\u00e9n soporta la firma tradicional con par de claves para entornos donde la firma keyless no es factible (redes air-gapped, requisitos regulatorios para custodia espec\u00edfica de claves). Generas un par de claves con El permiso Notation<\/a> es el cliente CLI para la especificaci\u00f3n Notary v2, un proyecto CNCF respaldado principalmente por Microsoft y AWS. Donde Cosign fue construido espec\u00edficamente para el ecosistema Sigstore, Notation fue dise\u00f1ado para integrarse con infraestructura PKI empresarial y flujos de trabajo existentes de certificados X.509.<\/p>\n Notation utiliza firmas COSE (CBOR Object Signing and Encryption)<\/strong> almacenadas como artefactos OCI adjuntos a la imagen firmada usando la especificaci\u00f3n ORAS<\/a> (OCI Registry As Storage). Al igual que Cosign, esto significa que las firmas residen en el registro OCI junto a las im\u00e1genes.<\/p>\n Notation utiliza una arquitectura de plugins para la gesti\u00f3n de claves. En lugar de manejar las claves directamente, delega en plugins que se comunican con almacenes de claves externos:<\/p>\n Este modelo de plugins es una opci\u00f3n natural para empresas que ya tienen gesti\u00f3n centralizada de claves e infraestructura PKI. La clave de firma nunca sale del HSM o cloud KMS \u2014 Notation env\u00eda el digest al plugin, y el plugin devuelve la firma.<\/p>\n Notation utiliza un sistema de pol\u00edticas de confianza<\/strong> basado en JSON para la verificaci\u00f3n. Defines qu\u00e9 registros, repositorios e im\u00e1genes conf\u00edas y qu\u00e9 certificados o cadenas de certificados est\u00e1n autorizados para firmarlos. Esto es poderoso para escenarios de gobernanza empresarial donde diferentes equipos tienen diferentes autoridades de firma.<\/p>\n GPG (GNU Privacy Guard) es el veterano del mundo de la firma. Mucho antes de que existieran las herramientas de firma nativas para contenedores, GPG se usaba para firmar todo, desde correos electr\u00f3nicos hasta commits de Git y paquetes de Linux. Algunos equipos a\u00fan usan GPG para firmar im\u00e1genes container, particularmente a trav\u00e9s de herramientas como Docker Content Trust (DCT) o firmando manifiestos de im\u00e1genes fuera de banda.<\/p>\n La firma GPG de contenedores t\u00edpicamente sigue uno de dos patrones:<\/p>\n Docker Content Trust (DCT) utiliza un enfoque relacionado pero distinto basado en The Update Framework (TUF), con Notary v1 como backend. Aunque DCT usa primitivos criptogr\u00e1ficos diferentes al GPG puro, comparte el mismo desaf\u00edo fundamental: la gesti\u00f3n de claves de larga duraci\u00f3n.<\/p>\n La mayor debilidad de GPG en un contexto CI\/CD es la gesti\u00f3n de claves:<\/p>\n Observa c\u00f3mo la clave privada debe almacenarse como un secreto de CI\/CD e inyectarse en tiempo de ejecuci\u00f3n \u2014 exactamente el tipo de gesti\u00f3n de secretos de larga duraci\u00f3n que la firma keyless fue dise\u00f1ada para eliminar.<\/p>\nCosign y el Ecosistema Sigstore<\/h2>\n
Descripci\u00f3n General<\/h3>\n
Firma Keyless con Fulcio y Rekor<\/h3>\n
\n
\n
Firma Basada en Claves<\/h3>\n
cosign generate-key-pair<\/code> y firmas con cosign sign --key cosign.key<\/code>.<\/p>\nEjemplo de Integraci\u00f3n CI\/CD: GitHub Actions<\/h3>\n
# .github\/workflows\/sign.yml\njobs:\n sign:\n runs-on: ubuntu-latest\n permissions:\n id-token: write # Required for keyless signing\n packages: write # Required to push signatures to GHCR\n steps:\n - uses: sigstore\/cosign-installer@v3\n\n - name: Sign the container image (keyless)\n env:\n COSIGN_EXPERIMENTAL: 1\n run: |\n cosign sign --yes ghcr.io\/myorg\/myapp@sha256:abc123...\n\n - name: Verify the signature\n run: |\n cosign verify \\\n --certificate-oidc-issuer https:\/\/token.actions.githubusercontent.com \\\n --certificate-identity-regexp https:\/\/github.com\/myorg\/myapp\/.github\/workflows\/* \\\n ghcr.io\/myorg\/myapp@sha256:abc123...\n<\/code><\/pre>\nid-token: write<\/code> es la pieza cr\u00edtica \u2014 permite que GitHub Actions genere el token OIDC que Fulcio usa para emitir el certificado de firma. Sin secretos que configurar, sin claves que almacenar. Para un recorrido pr\u00e1ctico, consulta nuestro Laboratorio de Firma Keyless con Cosign<\/a>.<\/p>\nFortalezas<\/h3>\n
\n
Limitaciones<\/h3>\n
\n
Notation y Notary v2<\/h2>\n
Descripci\u00f3n General<\/h3>\n
Gesti\u00f3n de Claves con Plugins<\/h3>\n
\n
Pol\u00edticas de Confianza y Almacenes de Confianza<\/h3>\n
\/\/ trustpolicy.json\n{\n \"version\": \"1.0\",\n \"trustPolicies\": [\n {\n \"name\": \"production-images\",\n \"registryScopes\": [\"registry.example.com\/prod\/*\"],\n \"signatureVerification\": {\n \"level\": \"strict\"\n },\n \"trustStores\": [\"ca:production-ca\"],\n \"trustedIdentities\": [\"x509.subject: CN=prod-signer, O=MyOrg\"]\n }\n ]\n}\n<\/code><\/pre>\nEjemplo de Integraci\u00f3n CI\/CD: GitHub Actions con AWS Signer<\/h3>\n
# .github\/workflows\/notation-sign.yml\njobs:\n sign:\n runs-on: ubuntu-latest\n permissions:\n id-token: write # For AWS OIDC federation\n steps:\n - name: Configure AWS credentials\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/signer-role\n aws-region: us-east-1\n\n - name: Setup Notation\n uses: notaryproject\/notation-action\/setup@v1\n\n - name: Install AWS Signer plugin\n run: |\n notation plugin install \\\n --url https:\/\/d2hvyiie56hcat.cloudfront.net\/linux\/amd64\/plugin\/latest\/notation-aws-signer-plugin.zip\n\n - name: Sign the container image\n run: |\n notation sign \\\n --plugin com.amazonaws.signer.notation.plugin \\\n --id arn:aws:signer:us-east-1:123456789012:\/signing-profiles\/MyProfile \\\n registry.example.com\/myapp@sha256:abc123...\n<\/code><\/pre>\nFortalezas<\/h3>\n
\n
Limitaciones<\/h3>\n
\n
GPG: El Enfoque Tradicional<\/h2>\n
Descripci\u00f3n General<\/h3>\n
C\u00f3mo Funciona la Firma GPG para Contenedores<\/h3>\n
\n
gpg --detach-sign<\/code>, y almacena el archivo .sig<\/code> junto a la imagen (en un almac\u00e9n de artefactos separado, bucket S3 o repositorio Git).<\/li>\n\/etc\/containers\/policy.json<\/code>).<\/li>\n<\/ul>\nDesaf\u00edos de la Gesti\u00f3n de Claves<\/h3>\n
\n
Ejemplo de Integraci\u00f3n CI\/CD: GitLab CI con GPG<\/h3>\n
# .gitlab-ci.yml\nsign-image:\n stage: sign\n image: alpine:latest\n before_script:\n - apk add --no-cache gnupg skopeo\n - echo \"$GPG_PRIVATE_KEY\" | gpg --batch --import\n script:\n - skopeo copy \\\n --sign-by signing-key@myorg.com \\\n docker:\/\/registry.example.com\/myapp:${CI_COMMIT_SHORT_SHA} \\\n docker:\/\/registry.example.com\/myapp:${CI_COMMIT_SHORT_SHA}\n variables:\n GPG_PRIVATE_KEY: $GPG_SIGNING_KEY # Stored in CI\/CD variables\n<\/code><\/pre>\nFortalezas<\/h3>\n
\n
Limitaciones<\/h3>\n
\n
Comparaci\u00f3n Lado a Lado<\/h2>\n