Secrets Kubernetes : SOPS, External Secrets ou Vault ?

Un secret Kubernetes ne se réduit pas à un objet. Un mot de passe de base de données part d'une source (un fichier chiffré dans Git, un coffre, un fournisseur externe), devient un objet Secret stocké dans etcd, puis une variable d'environnement ou un fichier monté dans un pod. Chaque étape a son propre lecteur et son propre délai. Pour un lead DevOps ou un responsable plateforme qui exploite déjà Kubernetes et GitOps, la question utile n'est donc pas quel outil est le meilleur, mais quelle étape chacun contrôle, et si une rotation atteint réellement le processus qui utilise la valeur.

Cet article compare trois outils qui n'interviennent pas au même endroit : SOPS, qui chiffre des fichiers versionnés ; External Secrets Operator (ESO), qui synchronise une source externe vers des objets Secret ; HashiCorp Vault, qui stocke, versionne et peut révoquer des secrets. Il s'appuie sur la documentation officielle et sur un laboratoire que nous avons mené, dont les limites sont indiquées dans le texte.

Suivre un secret de sa source jusqu'au processus

La décision commence par une carte. Un secret traverse au moins cinq états, et chacun répond à une question différente : qui peut modifier la valeur, qui peut la lire, à quel moment elle devient lisible en clair, et combien de temps une nouvelle valeur met pour atteindre le processus.

1. La source : la valeur de référence, dans un coffre, chez un fournisseur ou dans un fichier chiffré.
2. Le dépôt : un fichier Git, chiffré ou non, qui reste dans l'historique et chez tous ceux qui peuvent cloner le dépôt.
3. Le rendu : les manifestes générés par Helm, Kustomize ou un plugin, qui peuvent contenir la valeur pendant la génération.
4. L'objet Secret : stocké dans etcd, la base de données du plan de contrôle.
5. Le pod : la valeur, copiée dans l'environnement du processus ou écrite dans un fichier monté.

Les documentations officielles fixent les bornes de chaque état. Par défaut, les Secrets Kubernetes sont stockés non chiffrés dans etcd. Le chiffrement au repos existe, mais il ne s'applique qu'aux ressources écrites après sa configuration : les ressources déjà présentes restent non chiffrées tant qu'elles ne sont pas réécrites. Le base64 utilisé pour les données d'un Secret obscurcit la valeur sans la protéger, comme le rappelle la documentation Kubernetes. Enfin, un volume monté depuis un Secret est mis à jour de façon éventuellement cohérente, par un kubelet qui conserve son propre cache.

Le contrôle d'accès suit la même logique. La documentation RBAC précise que le droit get sur les Secrets permet de lire leur contenu, et que list et watch le permettent aussi, puisqu'une réponse de liste contient le contenu de chaque Secret. Elle précise surtout qu'une personne autorisée à créer un pod dans un namespace peut lire n'importe quel Secret de ce namespace, y compris indirectement, en créant par exemple un Deployment.

Choisir SOPS, External Secrets ou Vault selon l'étape qu'on veut contrôler

Les trois outils ne se remplacent pas. SOPS agit sur le fichier versionné, ESO sur la synchronisation vers le cluster, Vault sur le stockage et la durée de vie du secret. La question à poser est donc double : quelle étape devons-nous contrôler, et laquelle est déjà couverte par la plateforme ?

SOPS est un éditeur de fichiers chiffrés pour les formats YAML, JSON, ENV, INI et BINARY. Il chiffre avec AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS, age et PGP, et dispose aussi d'une intégration avec le moteur Transit de HashiCorp Vault et avec OpenBao.

ESO lit deux ressources. L'ExternalSecret décrit ce qu'il faut récupérer, le SecretStore décrit comment accéder au fournisseur. Un SecretStore est lié à un namespace et ne peut pas référencer des ressources d'un autre namespace. La référence d'ESO donne ses exemples en external-secrets.io/v1. Son provider Vault prend en charge plusieurs méthodes d'authentification, dont l'authentification Kubernetes, et ne gère que le moteur KV, en version 1 ou 2 (version 2 par défaut).

Vault stocke, génère ou chiffre des données. Certains moteurs génèrent des identifiants dynamiques à la demande, et tout secret dynamique porte un bail que Vault révoque à expiration. KV version 2 conserve des versions et sépare la suppression douce de la suppression définitive. Un serveur en mode développement, en revanche, garde tout en mémoire, sans TLS, et perd ses données à chaque redémarrage : la documentation Vault le réserve aux essais.

Les trois peuvent se combiner. SOPS convient aux fichiers de configuration versionnés dont les valeurs ne passent pas par un coffre. ESO convient aux valeurs que la plateforme doit tirer d'un coffre ou d'un fournisseur. Vault s'impose quand il faut des versions, des baux ou des identifiants dynamiques.

Dans un laboratoire local du 8 octobre 2026 (cluster kind à un seul nœud sous Kubernetes v1.37.0 ; External Secrets Operator 2.12.0 ; Vault 2.0.4 en mode développement, chart 0.34.1 ; SOPS 3.13.3 avec age v1.3.1), nous avons chiffré un Secret fictif avec SOPS. Avec l'option --encrypted-regex '^(data|stringData)$' utilisée dans le laboratoire, seules les valeurs ont été chiffrées : le type, le nom, le namespace, les labels et les noms de clés restaient lisibles. Modifier le nom du Secret dans le fichier chiffré a été refusé avec une erreur de MAC mismatch, et le déchiffrement avec une autre clé age a échoué. Ce test ne porte que sur ce fichier et cette version de SOPS. Le laboratoire ne couvre qu'un nœud, Vault en mode développement sans haute disponibilité, un seul moteur KV et des tests de panne joués une seule fois : les limites complètes sont données en fin d'article.

Réduire l'exposition dans Git, dans le rendu GitOps et dans les droits du cluster

Chiffrer dans Git ne supprime ni le Secret Kubernetes, ni son stockage, ni sa surface d'accès. Une fois le fichier déchiffré et appliqué, on retrouve un objet qu'un détenteur de get sur les Secrets du namespace peut lire. Le chiffrement protège le dépôt, pas le cluster.

Le laboratoire a montré un point de vigilance supplémentaire. Appliqué côté client, par sops --decrypt puis kubectl apply -f - (kubectl 1.36.3), à partir d'un manifeste stringData, le Secret porte dans son annotation kubectl.kubernetes.io/last-applied-configuration la valeur en clair. Nous n'avons pas testé l'application côté serveur (server-side apply) ni d'autre méthode d'application, et la documentation consultée ne traite pas ce cas. Avant de choisir un flux de déploiement, vérifiez ce que cette annotation conserve dans votre cluster, et évitez de laisser un poste de travail conserver un manifeste déchiffré.

Le rendu GitOps pose un problème voisin. La page de gestion des secrets d'Argo CD indique qu'Argo CD « needs access to the secrets, which increases the risk of leaking them », c'est-à-dire qu'il doit accéder aux secrets, ce qui augmente le risque de fuite. Elle met en garde contre l'injection de secrets pendant la génération des manifestes : les manifestes produits par un plugin, avec les secrets injectés, sont mis en cache dans son instance Redis. Elle recommande en revanche les solutions à opérateur côté cluster de destination, et nomme External Secrets Operator. Le choix du flux GitOps lui-même est traité dans GitOps en production : Argo CD ou Flux, santé des applications et nettoyage des orphelins ; la structure des applications est traitée dans Argo CD App-of-Apps et ApplicationSet : amorcer un cluster sans masquer les dépendances.

Le contrôle d'accès se vérifie par namespace. Le laboratoire a utilisé une fiche de droits avec kubectl auth can-i et l'usurpation d'identité (impersonation), sans jeton utilisateur réel :

Trois lignes méritent une lecture attentive. Le contrôleur ESO dispose, dans le laboratoire, de droits sur les Secrets de tout le cluster : c'est l'un des composants les plus sensibles de la plateforme. L'application n'a aucun droit d'API, son ServiceAccount ne monte même pas de jeton, et elle lit le Secret uniquement par le montage fait par le kubelet. Côté Vault, la politique n'accorde que la lecture sur le chemin secret/data/ctn-lab/ et ses sous-chemins, et le rôle n'accepte que le ServiceAccount prévu.

Le test le plus instructif concerne le créateur de pod. Un utilisateur qui peut créer des pods, mais pas lire les Secrets, a été refusé par get secret. Un pod qui montait le Secret a pourtant affiché sa valeur. Le droit de créer des pods vaut donc droit de lire les Secrets du namespace, ce que la documentation Kubernetes énonce. Le laboratoire n'a pas testé les politiques d'admission (Pod Security Admission, Kyverno) qui pourraient restreindre le montage d'un Secret par un créateur de pod.

Faire tourner un secret jusqu'au processus qui le lit

Une rotation comporte quatre temps : la nouvelle valeur est écrite à la source ; ESO la relit selon refreshInterval et met à jour le Secret ; le kubelet met à jour le fichier monté ; l'application relit ou non sa valeur. ESO ne couvre pas ce dernier temps : c'est celui que le laboratoire a mesuré.

La référence d'ESO définit refreshInterval comme la durée avant de relire les valeurs chez le fournisseur. La valeur par défaut du type d'API est d'une heure (1h0m0s), et zéro signifie une récupération unique. Le laboratoire a fixé 15 secondes pour mesurer la propagation. La même référence définit refreshPolicy, dont la valeur par défaut est Periodic. Avec OnChange, le Secret n'est mis à jour que si les métadonnées ou la spécification de l'ExternalSecret changent. Le laboratoire a utilisé le mode par défaut ; OnChange n'a pas été testé.

Le manifeste de synchronisation du laboratoire, avec des valeurs fictives, tient en quelques lignes :

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: ctn-lab-app
  namespace: ctn-lab-app
spec:
  refreshInterval: 15s
  secretStoreRef:
    kind: SecretStore
    name: ctn-lab-vault
  target:
    name: ctn-lab-app-secret
  data:
    - secretKey: password
      remoteRef:
        key: ctn-lab/app
        property: password

Le protocole a utilisé une application busybox qui lisait la même valeur de trois façons : en variable d'environnement, dans un volume complet, et dans un fichier monté avec subPath. Elle écrivait une ligne toutes les 2 secondes. La valeur a été changée dans Vault trois fois (v2, v3, v4), et chaque délai est mesuré depuis l'écriture dans Vault :

Les plages retiennent les trois rotations valides. La documentation Kubernetes confirme deux points : le volume est mis à jour de façon éventuellement cohérente, avec un délai qui peut atteindre la période de synchronisation du kubelet plus le délai de propagation du cache ; un conteneur qui monte un Secret en subPath ne reçoit pas ces mises à jour. Elle ne dit pas que les variables d'environnement le reçoivent, et le laboratoire montre qu'elles n'ont pas changé pendant la fenêtre observée, dans la version testée.

L'annotation force-sync change le comportement de la lecture côté opérateur, pas côté pod. Avec refreshInterval porté à une heure pour isoler l'effet, le Secret n'avait pas changé 25 secondes après l'écriture dans Vault. Après l'annotation force-sync sur l'ExternalSecret, il a changé en 0,1 seconde (trois essais ; ce pas de mesure ne permet que de dire « moins d'une seconde »). Le pod déjà démarré n'a pas changé pour autant : le fichier monté suit le kubelet, et les variables suivent le redémarrage.

ESO ne redémarre aucune application. Dans le laboratoire, la nouvelle valeur n'a atteint la variable d'environnement qu'après un rollout restart. Les outils tiers qui redémarrent automatiquement des pods lorsqu'un Secret change n'ont pas été testés et ne sont pas décrits ici.

Pour une équipe, la conséquence est simple : une rotation n'est terminée qu'après une lecture de la valeur dans le processus. Il faut donc décider, pour chaque mode de montage, si l'application relit le fichier, si elle doit être redémarrée, et qui déclenche ce redémarrage dans le runbook de rotation.

Tester la panne du coffre et la suppression d'un ExternalSecret

Quand le coffre tombe, la question est ce que le cluster montre et ce qu'il garde. Dans le laboratoire, Vault a été arrêté et l'ExternalSecret est passé à Ready=False avec la raison SecretSyncedError et le message « could not get secret data from provider », visible à la première lecture montrant l'erreur, 16 secondes après l'arrêt (les lectures à 6 et 11 secondes indiquaient encore Ready=True). Le message de la condition est générique. La cause, un refus de connexion au service Vault, n'apparaît que dans les événements de l'ExternalSecret (UpdateFailed). Le SecretStore est resté Ready pendant la fenêtre observée ; ESO ne revalide un store que périodiquement (toutes les 5 minutes par défaut dans la version 2.12.0).

Le Secret Kubernetes a gardé sa dernière valeur pendant environ 72 secondes d'arrêt observées. Un pod redémarré pendant la panne a démarré avec cette valeur. Ce comportement protège la disponibilité du service, mais il masque la panne : sans alerte sur la condition Ready de l'ExternalSecret, la dérive ne se voit qu'à la prochaine rotation.

Le retour du coffre a été plus instructif. Vault est redevenu prêt en 5,8 secondes, mais en mode développement il avait perdu ses données et sa configuration d'authentification. Les événements sont alors passés à une erreur 403 (permission denied) à la connexion. Après recréation des données et de l'authentification, le Secret a été resynchronisé 37,8 secondes après la nouvelle écriture, soit au-delà de l'intervalle de 15 secondes. Ce délai n'a été observé qu'une fois, et nous n'avons pas vérifié dans le code la raison de ce retard.

La suppression d'un ExternalSecret obéit à sa politique de création. Avec creationPolicy Owner, valeur par défaut, le Secret porte une ownerReference vers l'ExternalSecret et disparaît avec lui. Dans le laboratoire, le Secret était absent dès la lecture suivante, en moins d'une seconde. Le pod en cours a conservé ses valeurs, même 90 secondes plus tard. Un pod créé pendant cette absence est resté en ContainerCreating tant que le Secret n'a pas été recréé, pendant que l'ancien pod restait Running.

Avec creationPolicy Orphan, le Secret n'a pas d'ownerReference et il est resté après la suppression de l'ExternalSecret. Avec deletionPolicy Delete, la suppression de la clé distante a fait disparaître le Secret en moins de 3,1 secondes. Avec deletionPolicy Retain, valeur par défaut, la suppression de la clé dans Vault a laissé le Secret avec sa dernière valeur, et l'ExternalSecret est passé en SecretSyncedError. Ces deux derniers essais n'ont été joués qu'une fois.

Checklist avant mise en production

• Fixer les versions testées : version d'External Secrets Operator, version de l'API (external-secrets.io/v1), version de SOPS, version de Vault et version de Kubernetes.
• Ne pas utiliser un serveur Vault en mode développement. Prévoir un serveur persistant, dont la configuration d'authentification et les politiques sont décrites dans un dépôt versionné et peuvent être rejouées.
• Lister, par namespace, qui peut get, list ou create des pods. Traiter le droit de créer un pod comme un droit de lecture des Secrets du même namespace.
• Tester la rotation pour chaque mode de montage (variable d'environnement, volume complet, subPath), mesurer le délai, et écrire dans le runbook le redémarrage à déclencher.
• Choisir creationPolicy et deletionPolicy en sachant qu'avec Owner la suppression de l'ExternalSecret supprime le Secret.
• Vérifier ce que l'annotation last-applied-configuration conserve après chaque mode d'application.
• Alerter sur la condition Ready=False des ExternalSecret, et lire les événements pour connaître la cause.
• Rejouer une panne de la source et son retour dans un environnement de préproduction, en notant l'état du Secret et des pods.
• Vérifier l'état du chiffrement au repos d'etcd. Le laboratoire ne l'a pas testé ; la documentation présente KMS v2, stable depuis Kubernetes v1.29, comme un bon choix lorsqu'un outil tiers gère les clés.

Si vous souhaitez faire examiner votre chaîne de gestion des secrets et son exploitation avant la mise en production, la page Mise en production Kubernetes : ouvrir par étapes présente notre offre sur ce sujet.

Sources officielles et limites de lecture

Les faits de méthode proviennent de la documentation officielle d'External Secrets Operator, de HashiCorp Vault, de SOPS, d'Argo CD et de Kubernetes, lue directement le 8 octobre 2026. Les versions stables relevées le même jour sont External Secrets Operator v2.12.0, SOPS v3.13.3, Argo CD v3.5.4 et Vault v2.1.2. Le laboratoire a utilisé External Secrets Operator 2.12.0, SOPS 3.13.3 et Vault 2.0.4 ; la version 2.1.2 de Vault n'a pas été testée.

Limites. Le laboratoire tourne sur un cluster kind à un seul nœud, avec Vault en mode développement : en mémoire, sans TLS, sans haute disponibilité, avec un seul réplicat. Il ne compte qu'un ExternalSecret et un fournisseur, Vault KV version 2. Il n'inclut aucun test de charge. Les délais du volume dépendent de la période de synchronisation du kubelet et de la configuration du cluster : ils ne sont pas des garanties ni des valeurs de production. Une première exécution de la rotation a mal sélectionné le pod après le redémarrage ; sa mesure préliminaire (Secret à 11,6 s, volume à 54,4 s) n'entre pas dans les plages ci-dessus, qui ne retiennent que les trois rotations valides. Les pannes, la suppression et le test du créateur de pod n'ont été joués qu'une fois.

Non testés : SOPS avec un fournisseur KMS, ksops ou Flux ; la gestion et la rotation de la clé age ; les moteurs dynamiques de Vault, les baux, les journaux de Vault et Vault Agent ou le pilote CSI ; les politiques d'admission ; le chiffrement au repos d'etcd ; les rechargeurs tiers.

Sources

1. Documentation External Secrets Operator, présentation générale, https://external-secrets.io/latest/introduction/overview/, consultée le 08/10/2026.
2. Documentation External Secrets Operator, référence ExternalSecret, https://external-secrets.io/latest/api/externalsecret/, consultée le 08/10/2026.
3. Documentation External Secrets Operator, référence SecretStore, https://external-secrets.io/latest/api/secretstore/, consultée le 08/10/2026.
4. Documentation External Secrets Operator, fournisseur HashiCorp Vault, https://external-secrets.io/latest/provider/hashicorp-vault/, consultée le 08/10/2026.
5. Documentation HashiCorp Vault, moteurs de secrets, https://developer.hashicorp.com/vault/docs/secrets, consultée le 08/10/2026.
6. Documentation HashiCorp Vault, KV version 2, https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2, consultée le 08/10/2026.
7. Documentation HashiCorp Vault, baux (leases), https://developer.hashicorp.com/vault/docs/concepts/lease, consultée le 08/10/2026.
8. Documentation HashiCorp Vault, serveur en mode développement, https://developer.hashicorp.com/vault/docs/concepts/dev-server, consultée le 08/10/2026.
9. Dépôt officiel SOPS, https://github.com/getsops/sops, consulté le 08/10/2026.
10. Documentation SOPS, https://getsops.io/docs/, consultée le 08/10/2026.
11. Documentation Argo CD, gestion des secrets (version stable), https://argo-cd.readthedocs.io/en/stable/operator-manual/secret-management/, consultée le 08/10/2026.
12. Documentation Kubernetes, Secrets, https://kubernetes.io/docs/concepts/configuration/secret/, consultée le 08/10/2026.
13. Documentation Kubernetes, chiffrement des données au repos, https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/, consultée le 08/10/2026.
14. Documentation Kubernetes, bonnes pratiques RBAC, https://kubernetes.io/docs/concepts/security/rbac-good-practices/, consultée le 08/10/2026.
15. Versions d'External Secrets Operator, https://github.com/external-secrets/external-secrets/releases, consultées le 08/10/2026.
16. Versions de SOPS, https://github.com/getsops/sops/releases, consultées le 08/10/2026.
17. Versions de HashiCorp Vault, https://github.com/hashicorp/vault/releases, consultées le 08/10/2026.
18. Versions d'Argo CD, https://github.com/argoproj/argo-cd/releases, consultées le 08/10/2026.
19. Documentation SOPS, intégration HashiCorp Vault et OpenBao, https://getsops.io/docs/usage/identities/hashicorp-vault-openbao/, consulté le 08/10/2026.
20. Types d'API ExternalSecret v1 (External Secrets Operator v2.12.0), https://github.com/external-secrets/external-secrets/blob/v2.12.0/apis/externalsecrets/v1/externalsecret_types.go, consulté le 08/10/2026.
21. Options du contrôleur (External Secrets Operator v2.12.0, cmd/controller/root.go), https://github.com/external-secrets/external-secrets/blob/v2.12.0/cmd/controller/root.go, consulté le 08/10/2026.