Gestion des Secrets Kubernetes en 2026 : External Secrets, Vault et Questions d'Entretien

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.

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 :

# 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 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 :

# 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.

# 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, permet aux pods de s'authentifier sans distribuer de credentials de longue durée.

La configuration de l'authentification Vault nécessite trois étapes :

# 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 :

# 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 :

# 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 automatise ce processus :

# 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) :

# 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 :

# 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 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 :

# 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 :

# 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