8 min. de lecture
Un Secret Kubernetes ne stocke les valeurs sensibles, dans son état de livraison, qu’en texte encodé en Base64. Quiconque connaît les valeurs les lit en clair en quelques secondes. Le danger devient réel lorsque ces Secrets se retrouvent dans le dépôt Git, où ils demeurent pour toujours dans l’historique. Deux méthodes éprouvées permettent de sortir les secrets du texte clair sans abandonner le workflow GitOps. Le choix dépend de l’endroit où doit se trouver la source de vérité.
Les points clés en bref
- Base64 n’est pas un chiffrement : les Secrets Kubernetes sont stockés par défaut dans etcd simplement encodés. Quiconque a accès à etcd ou à l’API les lit en clair. La protection ne vient qu’avec le chiffrement au repos et des droits API rigoureux.
- Le texte clair dans Git est l’erreur qui coûte cher : un secret commité une fois reste dans l’historique. Rien qu’en 2025, GitGuardian a découvert 28,65 millions de secrets codés en dur dans des dépôts publics, soit un tiers de plus que l’année précédente.
- La source de vérité est déterminante : External Secrets récupère les secrets depuis un coffre externe, Sealed Secrets les chiffre pour Git. Le choix dépend du système qui gère le Secret.
En lien :Le cloud natif mûrit avec Kubernetes 1.34 / OpenTofu vs. Terraform
Pourquoi un Secret Kubernetes n’a rien de secret
Qu’est-ce qu’un Secret Kubernetes ? Un Secret Kubernetes est un objet qui sépare les données sensibles, comme les mots de passe, les tokens ou les clés, de la configuration applicative. Les valeurs sont stockées par défaut en Base64 dans le stockage central etcd. Base64 est un encodage, pas un chiffrement : le Secret est donc lisible en clair par quiconque dispose d’un accès à etcd ou à l’API.
C’est précisément là que commence le risque opérationnel. De nombreuses équipes traitent l’objet Secret comme protégé parce que la valeur ne semble pas immédiatement lisible. En réalité, l’encodage n’est qu’une forme de transport. Sans mesures supplémentaires, le secret est exposé : dans etcd, dans chaque objet de réponse de l’API et dans chaque sauvegarde du cluster qui enregistre l’état.
La première ligne de défense est donc le chiffrement d’etcd lui-même, combiné à des droits d’accès stricts sur l’API. Cela protège le Secret au repos, mais ne résout pas le second problème, plus grave : le chemin du secret vers la configuration. C’est là que se produit la véritable erreur opérationnelle.
Quand le texte en clair atterrit dans Git
GitOps déplace délibérément la configuration vers le dépôt. Consigner le secret en même temps constitue l’erreur fondamentale. Un secret une fois commis demeure dans l’historique, même si la modification suivante le supprime. Faire tourner la clé ne supprime pas l’ancien secret : cela en ajoute simplement un second.
Ce chiffre public sous-estime le risque interne. Les dépôts internes contiennent, selon les mêmes analyses, environ six fois plus de secrets codés en dur que les dépôts publics, car l’impression de cloisonnement réduit la vigilance. Le risque ne disparaît pas avec le temps : une part significative des secrets ayant fuité il y a des années et toujours valides reste exploitable aujourd’hui. Un secret dans l’historique Git demeure un risque ouvert tant qu’il est valide.
Deux solutions : External Secrets et Sealed Secrets
Les deux approches résolvent le même problème, mais interviennent à des points différents du workflow. L’External Secrets Operator maintient le secret en dehors du cluster et le récupère à la demande. Sealed Secrets chiffre le secret de sorte qu’aucun texte en clair ne réside dans le dépôt. L’élément décisif est de savoir quel système doit être la source de vérité pour le secret.
| Critère | External Secrets Operator | Sealed Secrets |
|---|---|---|
| Source de vérité | coffre-fort externe | le dépôt Git |
| Ce qui réside dans Git | une simple référence | le secret chiffré |
| Rotation | centralisée dans le coffre, automatique | rechiffrement et nouveau commit requis |
| Dépendance | le service externe doit être accessible | clé du contrôleur dans le cluster |
| Adapté à | coffre-fort existant, nombreux clusters | GitOps pur sans coffre-fort externe |
Pour les équipes disposant d’un coffre-fort centralisé comme HashiCorp Vault ou un gestionnaire de secrets cloud, l’External Secrets Operator constitue généralement le meilleur choix. Le secret reste en un seul endroit, la rotation s’y effectue, et Kubernetes ne reçoit qu’une copie temporaire. Pour ceux qui souhaitent se passer d’un service externe et tout conserver dans le dépôt, Sealed Secrets est la bonne option, mais ils devront sécuriser et faire tourner la clé du contrôleur dans le cluster. Les outils eux-mêmes nécessitent également une maintenance : une vulnérabilité signalée en 2026 dans Sealed Secrets montre que le mécanisme de protection lui-même peut être une cible à patcher.
Ce qui consolide la gestion sécurisée des secrets et ce qui la fragilise
C’est dans les détails de la mise en œuvre que se joue la différence entre une protection réelle et un simple sentiment de sécurité. Les pratiques suivantes permettent de distinguer l’une de l’autre.
Ce qui fragilise
- Considérer le secret Base64 comme protégé tout en laissant etcd non chiffré
- Committer des secrets une seule fois en comptant sur une suppression ultérieure
- Des clés à longue durée de vie sans rotation ni date d’expiration
- Un accès au contrôleur ou au coffre aussi large que l’accès normal au cluster
Ce qui consolide
- Chiffrer etcd et limiter strictement l’accès à l’API
- Ne jamais committer de secrets en clair, appliquer une méthode de façon cohérente
- Une durée de validité courte et une rotation automatique comme standard
- Maintenir les clés du coffre et du contrôleur séparées et avec des droits restreints
Le dénominateur commun est une posture simple : un secret n’est jamais plus sécurisé que son maillon le plus faible. Démasquer le Base64, chiffrer etcd et appliquer une méthode de manière cohérente demande moins d’efforts que de gérer les conséquences d’une clé compromise. Les outils sont matures et disponibles gratuitement. Ce qui fait défaut, c’est le plus souvent la décision de prendre le secret plus au sérieux que son encodage.
Foire aux questions
Les Secrets Kubernetes sont-ils chiffrés?
Pas par défaut. Les valeurs sont stockées en Base64 dans etcd, et le Base64 est un encodage, pas un chiffrement. Quiconque a accès à etcd ou à l’API peut les lire en clair. Le vrai chiffrement au repos doit être activé séparément pour etcd, avec des droits d’accès stricts.
Que fait l’External Secrets Operator?
Il lit les secrets depuis un coffre externe comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault, puis génère automatiquement des Secrets Kubernetes natifs. La source de vérité reste dans le coffre; dans le cluster, seule une copie synchronisée est présente. Dans le dépôt ne figure qu’une référence, jamais le secret lui-même.
Comment fonctionnent les Sealed Secrets?
Un secret est chiffré avec une clé publique que seul un contrôleur dans le cluster peut déchiffrer. L’objet chiffré peut être commité en toute sécurité dans le dépôt Git. Le contrôleur le déchiffre lors de l’application dans le cluster pour en faire un Secret ordinaire. Cela permet un vrai GitOps sans jamais stocker un secret en clair.
Quelle méthode choisir?
Cela dépend de l’emplacement souhaité pour la source de vérité. S’il existe déjà un coffre centralisé et plusieurs clusters, l’External Secrets Operator est adapté. Si tout doit rester dans le dépôt sans service externe, les Sealed Secrets sont la solution la plus simple. Les deux sont éprouvés; la différence tient à l’emplacement du secret.
Que faire des secrets déjà présents dans Git?
Ils sont considérés comme compromis et doivent être renouvelés, pas seulement supprimés. La suppression dans la version actuelle laisse le secret dans l’historique. La seule voie sécurisée est d’invalider la clé ou le mot de passe concerné et d’en émettre un nouveau, puis de migrer vers l’une des deux approches propres.
Plus du réseau MBF Media
Source de l’image: image de couverture générée par IA (juin 2026), certificat C2PA intégré dans l’image
