Cosign et External Secrets Operator : une base de supply chain Kubernetes pour les MSP

Ce guide associe deux contrôles open source que les MSP peuvent appliquer sur une flotte Kubernetes gérée : signer et vérifier les images de conteneurs avec Sigstore Cosign, et garder les identifiants hors de Git avec External Secrets Operator. Ensemble, ils comblent deux des lacunes les plus courantes d'une supply chain Kubernetes — images non vérifiées et secrets codés en dur dans les manifestes — sans nouvelle plateforme ni dépendance à un fournisseur.

Signer au build, vérifier au déploiement

Cosign, qui fait partie du projet open source Sigstore, signe et vérifie les images de conteneurs afin qu'un cluster Kubernetes puisse confirmer qu'une image provient bien d'un pipeline de build approuvé avant son exécution. Le schéma qui compte pour les MSP est simple : signez chaque image au moment du build, puis vérifiez cette signature à l'admission ou au déploiement, et rejetez tout ce qui ne passe pas.

La signature peut utiliser des clés de longue durée que votre équipe de sécurité contrôle, ou le flux keyless de Sigstore, dans lequel Fulcio délivre un certificat de courte durée qui lie une clé éphémère à une identité OpenID Connect vérifiée — un système CI ou une personne — pendant que le registre de transparence Rekor horodate l'événement. La vérification a ensuite lieu là où une image est sur le point de s'exécuter : un admission controller ou une porte de déploiement vérifie la signature par rapport à une identité ou une clé approuvée, et bloque tout ce qui n'est pas signé ou fiable avant que cela n'atteigne un cluster géré.

Ce que la signature ne remplace pas

Une signature prouve la provenance — qu'un digest donné vient d'un pipeline ou d'une identité précise — mais elle ne dit rien sur la présence de vulnérabilités connues dans ce digest. Cosign est conçu pour accompagner un scanner d'images comme Trivy ou Grype, pas pour le remplacer : le scanner évalue ce qu'il y a dans l'image, la signature prouve d'où elle vient. Considérer "signé" comme synonyme de "sûr" laisse la moitié du contrôle de côté.

Garder les secrets hors de Git avec External Secrets Operator

External Secrets Operator est un contrôleur Kubernetes qui relie des gestionnaires de secrets externes — dont AWS Secrets Manager, HashiCorp Vault et Azure Key Vault — aux Secrets natifs de Kubernetes, afin que les identifiants n'aient plus besoin de résider dans un dépôt Git ou un chart Helm. Il surveille une ressource SecretStore ou ClusterSecretStore et synchronise les valeurs dans les Secrets Kubernetes selon une planification, sans que l'opérateur lui-même ait besoin de journaliser le texte en clair.

Limiter chaque ExternalSecret au namespace et à la charge de travail qui en a réellement besoin réduit le rayon d'impact si un pod est compromis. L'opérateur dépend malgré tout des contrôles d'accès et de la politique de rotation du gestionnaire de secrets sous-jacent : il sort les identifiants du contrôle de version, mais ne remplace pas la sécurité de ce gestionnaire.

Pourquoi cette combinaison compte pour les MSP

Les flottes Kubernetes gérées ont tendance à accumuler les deux problèmes à la fois : des secrets codés en dur par commodité, et des images tirées d'un registre sans contrôle de signature. Intégrer External Secrets dans le chemin de déploiement supprime l'excuse de stocker des identifiants dans les manifestes, tandis qu'une politique d'admission Cosign donne à un MSP une porte unique et auditable pour savoir si une image provient bien de son propre pipeline.

Aucun des deux outils n'est à lui seul un programme de sécurité complet. La vérification de Cosign ne vaut que ce que valent la gestion des clés et la confiance accordée aux émetteurs derrière elle, et le moindre privilège, la segmentation réseau et la réponse aux incidents restent des chantiers distincts. Combinés, ces deux contrôles forment cependant une base répétable applicable par tenant, avec un processus d'exception documenté pour ce qui n'est pas encore conforme.

Les MSP qui doivent prouver que ces contrôles résistent à un audit peuvent se tourner vers les services de cybersécurité d'Altovar, qui couvrent les tests d'intrusion, l'évaluation des vulnérabilités, la réponse aux incidents et la conformité NIS2/DORA/GDPR.

Ce qu'il faut faire

• Signez chaque image au moment du build et revérifiez-la à l'admission ou au déploiement ; ne faites jamais confiance à une signature issue du seul build.
• Testez d'abord le chemin d'échec : vérifiez qu'une image non signée ou altérée est bien rejetée avant de faire confiance à la porte en production.
• Associez Cosign à un scanner de vulnérabilités comme Trivy ou Grype, car une signature valide n'équivaut pas à un scan propre.
• Sortez chaque identifiant des manifestes et des charts Helm vers un SecretStore géré par External Secrets Operator.
• Limitez chaque ExternalSecret au namespace et à la charge de travail qui en a besoin, et faites tourner les clés ou les identifiants selon un calendrier défini.
• Documentez le processus d'exception pour ce qui n'est pas encore conforme, et validez les changements de politique dans un cluster hors production avant de les déployer sur toute la flotte.

Sources : GitHub — sigstore/cosign, documentation Sigstore, External Secrets Operator sur GitHub.