Chaque fois que vous r\u00e9cup\u00e9rez une image container et la d\u00e9ployez en production, vous accordez une confiance implicite \u00e0 cet artefact. Mais comment v\u00e9rifiez-vous<\/em> que l’image n’a pas \u00e9t\u00e9 alt\u00e9r\u00e9e ? Comment confirmez-vous qu’elle a r\u00e9ellement \u00e9t\u00e9 construite par votre pipeline CI\/CD et non inject\u00e9e par un attaquant ayant compromis votre registre ?<\/p>\n La signature d’images container r\u00e9sout ce probl\u00e8me en attachant une signature cryptographique \u00e0 vos images. Avant le d\u00e9ploiement, votre orchestrateur ou contr\u00f4leur d’admission peut v\u00e9rifier cette signature, garantissant que seules des images fiables et authentifi\u00e9es acc\u00e8dent \u00e0 votre environnement. C’est un pilier fondamental de la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement logicielle<\/strong> et une exigence dans des r\u00e9f\u00e9rentiels tels que SLSA<\/a> et NIST SSDF<\/a>.<\/p>\n Cependant, tous les outils de signature ne se valent pas. Les trois approches dominantes aujourd’hui \u2014 Cosign<\/strong> (issu du projet Sigstore), Notation<\/strong> (le client Notary v2) et GPG<\/strong> (l’approche traditionnelle) \u2014 pr\u00e9sentent chacune des compromis radicalement diff\u00e9rents en mati\u00e8re de gestion des cl\u00e9s, d’int\u00e9gration CI\/CD et de compatibilit\u00e9 avec l’\u00e9cosyst\u00e8me.<\/p>\n Dans ce guide, nous r\u00e9alisons une comparaison approfondie et pratique des trois outils afin de vous aider \u00e0 faire le bon choix pour vos pipelines.<\/p>\n Cosign est l’outil de signature d’images container du projet Sigstore<\/a>, d\u00e9sormais un projet dipl\u00f4m\u00e9 (graduated) sous la Linux Foundation. La mission de Sigstore est de rendre la signature logicielle omnipr\u00e9sente en supprimant le plus grand obstacle : la gestion des cl\u00e9s<\/strong>.<\/p>\n Cosign stocke les signatures en tant qu’artefacts OCI directement aux c\u00f4t\u00e9s de l’image sign\u00e9e dans le m\u00eame registre. Cela signifie qu’il n’y a aucun syst\u00e8me de stockage de signatures s\u00e9par\u00e9 \u00e0 maintenir \u2014 votre registre de conteneurs existant (Docker Hub, GitHub Container Registry, AWS ECR, Google Artifact Registry, etc.) remplit cette double fonction.<\/p>\n La fonctionnalit\u00e9 la plus r\u00e9volutionnaire de Cosign est la signature keyless<\/strong>. Au lieu de g\u00e9rer des cl\u00e9s de signature \u00e0 longue dur\u00e9e de vie, Cosign s’int\u00e8gre \u00e0 deux services :<\/p>\n Avec la signature keyless, le flux de travail se d\u00e9roule ainsi :<\/p>\n Cela \u00e9limine toute la cat\u00e9gorie de probl\u00e8mes li\u00e9s \u00e0 la rotation des cl\u00e9s, au stockage des cl\u00e9s et \u00e0 la compromission des cl\u00e9s. Il n’y a aucun secret \u00e0 longue dur\u00e9e de vie \u00e0 prot\u00e9ger.<\/p>\n Cosign prend \u00e9galement en charge la signature traditionnelle par paire de cl\u00e9s pour les environnements o\u00f9 le mode keyless n’est pas envisageable (r\u00e9seaux isol\u00e9s, exigences r\u00e9glementaires imposant une garde sp\u00e9cifique des cl\u00e9s). Vous g\u00e9n\u00e9rez une paire de cl\u00e9s avec La permission Notation<\/a> est le client CLI de la sp\u00e9cification Notary v2, un projet CNCF soutenu principalement par Microsoft et AWS. L\u00e0 o\u00f9 Cosign a \u00e9t\u00e9 con\u00e7u sp\u00e9cifiquement pour l’\u00e9cosyst\u00e8me Sigstore, Notation a \u00e9t\u00e9 pens\u00e9 pour s’int\u00e9grer aux infrastructures PKI d’entreprise et aux workflows de certificats X.509 existants.<\/p>\n Notation utilise des signatures COSE (CBOR Object Signing and Encryption)<\/strong> stock\u00e9es en tant qu’artefacts OCI attach\u00e9s \u00e0 l’image sign\u00e9e via la sp\u00e9cification ORAS<\/a> (OCI Registry As Storage). Comme Cosign, cela signifie que les signatures r\u00e9sident dans le registre OCI aux c\u00f4t\u00e9s des images.<\/p>\n Notation utilise une architecture de plugins pour la gestion des cl\u00e9s. Au lieu de manipuler les cl\u00e9s directement, il d\u00e9l\u00e8gue \u00e0 des plugins qui interfacent avec des coffres-forts de cl\u00e9s externes :<\/p>\n Ce mod\u00e8le de plugins est naturellement adapt\u00e9 aux entreprises disposant d\u00e9j\u00e0 d’une gestion centralis\u00e9e des cl\u00e9s et d’une infrastructure PKI. La cl\u00e9 de signature ne quitte jamais le HSM ou le KMS cloud \u2014 Notation envoie le digest au plugin, et le plugin renvoie la signature.<\/p>\n Notation utilise un syst\u00e8me de politiques de confiance<\/strong> bas\u00e9 sur JSON pour la v\u00e9rification. Vous d\u00e9finissez quels registres, d\u00e9p\u00f4ts et images vous faites confiance, ainsi que les certificats ou cha\u00eenes de certificats autoris\u00e9s \u00e0 les signer. Ceci est particuli\u00e8rement puissant pour les sc\u00e9narios de gouvernance d’entreprise o\u00f9 diff\u00e9rentes \u00e9quipes disposent de diff\u00e9rentes autorit\u00e9s de signature.<\/p>\n GPG (GNU Privacy Guard) est le v\u00e9t\u00e9ran du monde de la signature. Bien avant l’existence des outils de signature natifs pour conteneurs, GPG \u00e9tait utilis\u00e9 pour signer de tout \u2014 des courriels aux commits Git en passant par les paquets Linux. Certaines \u00e9quipes utilisent encore GPG pour signer des images container, notamment via Docker Content Trust (DCT) ou en signant les manifestes d’images de mani\u00e8re externe (out-of-band).<\/p>\n La signature GPG des conteneurs suit g\u00e9n\u00e9ralement l’un de ces deux sch\u00e9mas :<\/p>\n Docker Content Trust (DCT) utilise une approche apparent\u00e9e mais distincte bas\u00e9e sur The Update Framework (TUF), avec Notary v1 comme backend. Bien que DCT utilise des primitives cryptographiques diff\u00e9rentes du GPG brut, il partage le m\u00eame d\u00e9fi fondamental : la gestion de cl\u00e9s \u00e0 longue dur\u00e9e de vie.<\/p>\n La plus grande faiblesse de GPG dans un contexte CI\/CD est la gestion des cl\u00e9s :<\/p>\n Remarquez comment la cl\u00e9 priv\u00e9e doit \u00eatre stock\u00e9e en tant que secret CI\/CD et inject\u00e9e au moment de l’ex\u00e9cution \u2014 exactement le type de gestion de secrets \u00e0 longue dur\u00e9e de vie que la signature keyless a \u00e9t\u00e9 con\u00e7ue pour \u00e9liminer.<\/p>\nCosign et l’\u00e9cosyst\u00e8me Sigstore<\/h2>\n
Pr\u00e9sentation<\/h3>\n
Signature keyless avec Fulcio et Rekor<\/h3>\n
\n
\n
Signature bas\u00e9e sur des cl\u00e9s<\/h3>\n
cosign generate-key-pair<\/code> et signez avec cosign sign --key cosign.key<\/code>.<\/p>\nExemple d’int\u00e9gration 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> est l’\u00e9l\u00e9ment critique \u2014 elle permet \u00e0 GitHub Actions de g\u00e9n\u00e9rer le jeton OIDC que Fulcio utilise pour \u00e9mettre le certificat de signature. Aucun secret \u00e0 configurer, aucune cl\u00e9 \u00e0 stocker. Pour un tutoriel pratique pas \u00e0 pas, consultez notre Lab de signature keyless avec Cosign<\/a>.<\/p>\nPoints forts<\/h3>\n
\n
Limitations<\/h3>\n
\n
Notation et Notary v2<\/h2>\n
Pr\u00e9sentation<\/h3>\n
Gestion des cl\u00e9s avec des plugins<\/h3>\n
\n
Politiques de confiance et magasins de confiance<\/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>\nExemple d’int\u00e9gration CI\/CD : GitHub Actions avec 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>\nPoints forts<\/h3>\n
\n
Limitations<\/h3>\n
\n
GPG : l’approche traditionnelle<\/h2>\n
Pr\u00e9sentation<\/h3>\n
Fonctionnement de la signature GPG pour les conteneurs<\/h3>\n
\n
gpg --detach-sign<\/code>, et stocker le fichier .sig<\/code> aux c\u00f4t\u00e9s de l’image (dans un d\u00e9p\u00f4t d’artefacts s\u00e9par\u00e9, un bucket S3 ou un d\u00e9p\u00f4t Git).<\/li>\n\/etc\/containers\/policy.json<\/code>).<\/li>\n<\/ul>\nD\u00e9fis de la gestion des cl\u00e9s<\/h3>\n
\n
Exemple d’int\u00e9gration CI\/CD : GitLab CI avec 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>\nPoints forts<\/h3>\n
\n
Limitations<\/h3>\n
\n
Comparaison c\u00f4te \u00e0 c\u00f4te<\/h2>\n