# Gestion des Secrets Kubernetes en 2026 : External Secrets, Vault et Questions d'Entretien > Guide complet sur la gestion des secrets Kubernetes avec External Secrets Operator et HashiCorp Vault. Patterns de rotation automatique, intégration multi-cloud et questions d'entretien DevOps. - Published: 2026-09-02 - Updated: 2026-09-02 - Author: Anthony Fillion-Maillet - Tags: kubernetes, secrets, vault, external-secrets, security, devops - Reading time: 12 min --- La gestion des secrets Kubernetes reste l'un des défis de sécurité les plus critiques dans l'orchestration de conteneurs. Les Secrets Kubernetes natifs stockent les données sensibles en base64, ce qui ne fournit aucun chiffrement au repos par défaut et crée des risques de sécurité fréquemment explorés lors des entretiens d'embauche DevOps. > **Réponse Rapide pour Entretien** > > Lorsqu'on interroge sur la sécurité des secrets Kubernetes : les Secrets natifs sont encodés en base64, pas chiffrés. Les environnements de production nécessitent des gestionnaires de secrets externes comme HashiCorp Vault ou AWS Secrets Manager, synchronisés via External Secrets Operator (ESO). Cette séparation garantit que les secrets n'existent jamais dans les dépôts Git. ## Pourquoi les Secrets Kubernetes Natifs Sont Insuffisants La ressource Secret intégrée stocke les données dans etcd avec un encodage base64. Cet encodage est réversible avec une simple commande : ```bash # decoding-secret.sh # Décoder n'importe quelle valeur de secret Kubernetes instantanément kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d ``` Le base64 n'est pas du chiffrement. Toute personne ayant accès au cluster peut lire les valeurs des secrets. La [documentation Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/) avertit explicitement que les Secrets "ne sont pas chiffrés par défaut" et recommande d'activer le chiffrement au repos. Trois limitations principales affectent les déploiements en production : 1. **Aucune piste d'audit** : Les Secrets natifs ne journalisent pas qui a accédé à quelle valeur et quand 2. **Aucun mécanisme de rotation** : Changer un secret nécessite une intervention manuelle et un redémarrage des pods 3. **Incompatibilité GitOps** : Stocker des secrets chiffrés dans Git expose toujours le problème de gestion des clés de chiffrement ## Architecture d'External Secrets Operator External Secrets Operator (ESO) fait le pont entre Kubernetes et les systèmes de gestion de secrets externes. Publié comme projet CNCF Sandbox en 2023 et atteignant la version 0.10 en 2026, ESO supporte AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault et 15 autres backends. L'architecture implique trois ressources personnalisées : ```yaml # secret-store.yaml # ClusterSecretStore définit la connexion à Vault apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: vault-backend spec: provider: vault: server: "https://vault.internal:8200" path: "secret" version: "v2" auth: kubernetes: mountPath: "kubernetes" role: "external-secrets" serviceAccountRef: name: "external-secrets" namespace: "external-secrets" ``` Ce ClusterSecretStore configure ESO pour s'authentifier auprès de Vault en utilisant les tokens de compte de service Kubernetes. La méthode d'authentification `kubernetes` valide le JWT du compte de service contre l'API TokenReview du cluster. ```yaml # external-secret.yaml # ExternalSecret récupère et synchronise les données de secret réelles apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: database-credentials namespace: production spec: refreshInterval: 1h secretStoreRef: name: vault-backend kind: ClusterSecretStore target: name: db-secret creationPolicy: Owner data: - secretKey: username remoteRef: key: secret/data/production/database property: username - secretKey: password remoteRef: key: secret/data/production/database property: password ``` ESO interroge Vault toutes les heures (`refreshInterval: 1h`) et met à jour le Secret Kubernetes automatiquement. La politique `creationPolicy: Owner` garantit que le Secret est supprimé lorsque l'ExternalSecret est retiré. ## Patterns d'Intégration HashiCorp Vault Vault fournit des secrets dynamiques, une rotation automatique et une journalisation d'audit complète. La méthode d'authentification Kubernetes, documentée dans la [documentation Vault Kubernetes Auth](https://developer.hashicorp.com/vault/docs/auth/kubernetes), permet aux pods de s'authentifier sans distribuer de credentials de longue durée. La configuration de l'authentification Vault nécessite trois étapes : ```bash # vault-k8s-auth.sh # Activer la méthode d'authentification Kubernetes dans Vault vault auth enable kubernetes # Configurer Vault pour valider les tokens contre l'API Kubernetes vault write auth/kubernetes/config \ kubernetes_host="https://kubernetes.default.svc:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt # Créer un rôle qui lie les comptes de service aux policies vault write auth/kubernetes/role/external-secrets \ bound_service_account_names=external-secrets \ bound_service_account_namespaces=external-secrets \ policies=readonly-secrets \ ttl=1h ``` Cette configuration lie le compte de service `external-secrets` à une policy Vault. Le TTL limite la validité du token, forçant la ré-authentification et réduisant la surface d'attaque des tokens compromis. Pour les déploiements en production, la policy doit suivre les principes du moindre privilège : ```hcl # readonly-secrets.hcl # Policy Vault accordant un accès en lecture seule à des chemins spécifiques path "secret/data/production/*" { capabilities = ["read"] } path "secret/metadata/production/*" { capabilities = ["list"] } ``` Cette policy accorde un accès en lecture uniquement au chemin des secrets de production. Les équipes gérant différents environnements reçoivent des policies séparées avec des restrictions de chemin correspondantes. ## Rotation des Secrets Sans Interruption La rotation automatique empêche les secrets de devenir des vecteurs d'attaque périmés. ESO gère le côté Kubernetes, mais l'application doit recharger les secrets sans redémarrer. Deux approches existent pour une rotation sans interruption : **Secrets montés en volume avec surveillance de fichiers :** ```yaml # deployment-volume-secrets.yaml # Monter les secrets comme fichiers qui se mettent à jour automatiquement apiVersion: apps/v1 kind: Deployment metadata: name: api-server spec: template: spec: containers: - name: api image: api:v2.1.0 volumeMounts: - name: secrets mountPath: /etc/secrets readOnly: true volumes: - name: secrets secret: secretName: db-secret ``` Kubernetes met à jour les fichiers de secrets montés dans la période de synchronisation du kubelet (1 minute par défaut). L'application lit les credentials depuis `/etc/secrets/password` à chaque connexion à la base de données, récupérant les nouvelles valeurs sans redémarrage. **Reloader pour les secrets en variables d'environnement :** Les applications utilisant des variables d'environnement nécessitent des redémarrages de pods. [Stakater Reloader](https://github.com/stakater/Reloader) automatise ce processus : ```yaml # deployment-with-reloader.yaml # L'annotation déclenche un redémarrage progressif quand le secret change apiVersion: apps/v1 kind: Deployment metadata: name: api-server annotations: reloader.stakater.com/auto: "true" spec: template: spec: containers: - name: api envFrom: - secretRef: name: db-secret ``` Reloader surveille les mises à jour de Secrets et effectue des redémarrages progressifs, maintenant la disponibilité tout au long de la rotation. ## Questions d'Entretien sur les Secrets Kubernetes Les entretiens DevOps testent systématiquement la compréhension de la gestion des secrets. Ces questions apparaissent des niveaux junior aux niveaux senior : **Q : Quel encodage utilisent les Secrets Kubernetes, et pourquoi est-ce insuffisant pour la sécurité ?** Les Secrets utilisent l'encodage base64, qui est une transformation réversible, pas du chiffrement. Tout utilisateur avec les permissions `get` sur les Secrets peut décoder les valeurs. La sécurité nécessite le chiffrement au repos (activation du chiffrement etcd) et la restriction des permissions RBAC. **Q : Comment empêcher les secrets d'apparaître dans les dépôts Git lors de l'utilisation de GitOps ?** External Secrets Operator stocke uniquement des références aux secrets dans Git, pas les valeurs elles-mêmes. Le manifeste ExternalSecret contient le chemin vers le secret dans Vault ou AWS Secrets Manager, tandis que le secret réel ne touche jamais le dépôt. Sealed Secrets de Bitnami offre une approche alternative utilisant le chiffrement asymétrique. **Q : Expliquer la différence entre SecretStore et ClusterSecretStore.** SecretStore est limité au namespace : les ExternalSecrets dans le même namespace peuvent le référencer. ClusterSecretStore est à l'échelle du cluster : n'importe quel namespace peut le référencer. Utiliser ClusterSecretStore quand plusieurs équipes partagent une seule instance Vault, et SecretStore quand chaque namespace a des backends de secrets isolés. **Q : Comment fonctionne l'authentification Kubernetes dans Vault ?** Lorsqu'un pod s'authentifie auprès de Vault, il envoie son token JWT de compte de service. Vault valide ce token en contactant l'API TokenReview de Kubernetes. Si le token est valide et que le compte de service correspond à un rôle configuré, Vault émet un token Vault avec les policies associées. **Q : Quelle est la stratégie recommandée pour la rotation des secrets dans un environnement de production ?** Configurer `refreshInterval` dans ExternalSecret en dessous du TTL des credentials. Pour les applications utilisant des variables d'environnement, déployer Reloader pour automatiser les redémarrages progressifs. Pour les secrets montés en volume, s'assurer que l'application relit les fichiers plutôt que de mettre en cache les valeurs au démarrage. ## Intégration Multi-Cloud avec AWS et GCP Les organisations utilisant plusieurs fournisseurs cloud nécessitent des configurations ESO spécifiques à chaque provider. AWS utilise IRSA (IAM Roles for Service Accounts) : ```yaml # aws-secret-store.yaml # ClusterSecretStore pour AWS Secrets Manager avec IRSA apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: aws-secrets spec: provider: aws: service: SecretsManager region: eu-west-1 auth: jwt: serviceAccountRef: name: external-secrets-sa namespace: external-secrets ``` Le compte de service s'annote pour lier le rôle IAM : ```yaml # service-account-irsa.yaml # Compte de service avec annotation de rôle IAM apiVersion: v1 kind: ServiceAccount metadata: name: external-secrets-sa namespace: external-secrets annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/external-secrets ``` AWS effectue automatiquement la rotation des secrets créés via Secrets Manager avec une fonction Lambda. Combiné avec l'intervalle de rafraîchissement d'ESO, les secrets se propagent vers Kubernetes dans la période de polling configurée. ## Synchronisation de Secrets Multi-Cluster Les organisations exécutant plusieurs clusters nécessitent une distribution de secrets cohérente. Deux patterns répondent à ce besoin : **Hub-and-spoke avec ClusterSecretStore :** Tous les clusters se connectent à une instance Vault centrale. L'installation ESO de chaque cluster référence les mêmes secrets, et Vault gère le contrôle d'accès via des policies basées sur les namespaces. **Réplication avec Vault Enterprise :** Vault Enterprise supporte la réplication de performance entre régions. Chaque cluster se connecte à sa réplique Vault locale, réduisant la latence tout en maintenant la cohérence. La [documentation de réplication Vault](https://developer.hashicorp.com/vault/docs/enterprise/replication) couvre les modes de reprise après sinistre et de réplication de performance. ## Durcissement RBAC pour l'Accès aux Secrets Les rôles de cluster par défaut accordent un accès excessif aux secrets. Durcir le RBAC en créant des rôles minimaux : ```yaml # restricted-role.yaml # Rôle autorisant l'accès aux secrets uniquement dans un namespace spécifique apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-reader namespace: production rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"] resourceNames: ["db-secret", "api-key"] ``` Le champ `resourceNames` restreint l'accès aux secrets explicitement listés. Sans ce champ, le rôle accorde l'accès à tous les secrets du namespace. La journalisation d'audit capture les tentatives d'accès aux secrets : ```yaml # audit-policy.yaml # Policy d'audit Kubernetes pour les opérations sur les secrets apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: "" resources: ["secrets"] verbs: ["get", "list", "watch"] ``` Cette policy journalise la requête et la réponse complètes pour les opérations sur les secrets, permettant aux équipes de sécurité de détecter les patterns d'accès non autorisés. ## Checklist de Production pour les Secrets Kubernetes - Activer le chiffrement etcd au repos en utilisant la ressource API `EncryptionConfiguration` - Déployer External Secrets Operator v0.10+ avec ClusterSecretStore pointant vers Vault ou le fournisseur cloud - Configurer `refreshInterval` en dessous du TTL des credentials pour garantir que les secrets se mettent à jour avant expiration - Utiliser IRSA (AWS), Workload Identity (GCP) ou l'authentification Kubernetes (Vault) au lieu de credentials statiques - Restreindre RBAC avec `resourceNames` pour limiter l'accès aux secrets à des secrets nommés spécifiques - Activer la journalisation d'audit Kubernetes pour les opérations sur les secrets avec le niveau RequestResponse - Déployer Reloader pour les applications utilisant des variables d'environnement pour gérer les mises à jour de secrets - Tester la rotation des secrets en staging avant le déploiement en production - Documenter les procédures de récupération pour les pannes de backend de secrets affectant la planification des pods --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/fr/blog/devops/kubernetes-secrets-management-2026-external-secrets-vault-interview