Sigstore et Cosign : vérifier les images de conteneurs

Les tags de conteneurs sont des étiquettes pratiques, pas des identités immuables. Si un tag change ou si une image est remplacée, un déploiement peut exécuter un contenu jamais approuvé. Sigstore et Cosign permettent de signer et vérifier l’artefact par digest et identité du signataire.

Le mot critique est « vérifier ». Signer sans politique qui contrôle la source, le workflow et l’identité ne bloque pas un signataire non fiable.

Ce qu’ajoute Cosign

Cosign prend en charge signature par clé ou keyless, signatures attachées aux images, attestations et preuves de transparence. La documentation Sigstore montre que la vérification par identité contrôle à la fois certificat et émetteur OIDC.

Une bonne vérification répond à :

• la signature est-elle valide ?
• couvre-t-elle ce digest exact ?
• qui a signé et sous quel émetteur ?
• cette identité est-elle autorisée pour ce dépôt ?
• la provenance ou l’attestation requise existe-t-elle ?

La validité cryptographique est nécessaire ; la confiance vient de la comparaison aux attentes.

Signature keyless et identité

Dans un flux keyless, le workload obtient un certificat court après authentification OIDC. Cela réduit la gestion des clés privées longues, mais déplace l’attention vers l’identité du workflow et ses claims.

Restreignez la confiance au dépôt, workflow, branche ou environnement prévu. Accepter n’importe quel certificat d’un grand émetteur public est trop large.

Protégez le CI :

• revue obligatoire des workflows ;
• actions tierces épinglées ;
• isolation des pull requests non fiables ;
• permissions de token minimales ;
• séparation build, signature et déploiement ;
• runners éphémères si possible.

Signer le digest, déployer le digest

Construisez une fois, calculez le digest, générez provenance et SBOM, signez l’artefact immuable puis promouvez ce même digest. Ne reconstruisez pas chaque environnement en espérant un résultat identique.

À la vérification, contrôlez signature et claims. Au déploiement, référencez le digest et journalisez signataire et résultat.

Politique d’admission Kubernetes

Un contrôleur peut refuser une image non signée, signée par une identité inattendue ou sans attestation. Déployez progressivement :

1. inventoriez images et registres ;
2. définissez les identités par namespace ou workload ;
3. commencez en audit ;
4. corrigez les exceptions légitimes ;
5. appliquez aux environnements critiques ;
6. expirez les contournements.

La procédure break-glass doit être authentifiée, tracée, courte et revue. Un label permanent de contournement annule le contrôle.

Signatures, provenance et vulnérabilités

La signature prouve intégrité et identité. La provenance SLSA décrit le build. Le SBOM liste les composants. La threat intelligence de vulnérabilité évalue le risque. Le runtime observe le comportement.

Un build malveillant correctement signé reste malveillant. Combinez les contrôles.

Vérifiez les couches suspectes avec la réputation des hashes et enquêtez sur leurs destinations si le runtime révèle un trafic inattendu.

Réponse à incident

Après échec, stoppez la promotion et préservez digest, bundle, certificat, claims, registre et CI. Déterminez si l’image a changé, si le signataire est inattendu, si la politique dérive ou si le workflow est compromis.

Recherchez les déploiements du même digest et les artefacts du signataire suspect. Restreignez la confiance et reconstruisez seulement depuis une source saine.

Métriques

Suivez images déployées par digest, signatures vérifiées, échecs de politique, exceptions non signées, délai de traçage et rejets avant runtime. Les bypass périmés sont une dette de sécurité.

Conclusion

Cosign rend l’identité de l’image vérifiable ; la politique donne du sens au résultat. Liez signatures, digests et identités CI attendues, puis appliquez aux frontières registre et admission. Associez la sécurité des conteneurs à provenance, SBOM et runtime.