Architecture des Secrets Kubernetes expliquée avec des exemples pratiques

Intro

Les Secrets Kubernetes contiennent des identifiants et d’autres configurations sensibles afin que vos workloads puissent accéder à des bases de données, des API et des services sans intégrer de secrets dans les images ni dans le contrôle de version. Ce guide explique l’architecture des Secrets, montre comment les données circulent dans le cluster et fournit des procédures pratiques, vérifiées, pour configurer, diagnostiquer et récupérer après des pannes. L’accent est mis sur la sécurité opérationnelle : observer d’abord, changer la plus petite chose possible, vérifier le résultat, et documenter comment revenir en arrière.

Architecture en un coup d’œil

• Composants impliqués
• kube-apiserver : valide et stocke les objets Secret dans etcd.
• etcd : persiste les Secrets; les valeurs sont encodées en base64, pas chiffrées par défaut. Activez le chiffrement au repos pour les protéger.
• Admission/RBAC : contrôlent qui peut créer, mettre à jour, obtenir, lister ou surveiller (watch) les Secrets.
• kubelet : récupère les Secrets référencés par les Pods planifiés sur son nœud et les expose comme variables d’environnement ou volumes.
• Contrôleurs : déclenchent des déploiements progressifs (rollouts) et des redémarrages quand les spécifications de Pod changent.

• Flux de données

1. Vous créez un Secret via kubectl ou un contrôleur (GitOps, opérateur).
2. kube-apiserver le valide et l’écrit dans etcd.
3. Lorsqu’un Pod référence ce Secret, le kubelet du nœud concerné le récupère via un canal sécurisé.
4. Le Secret est exposé au conteneur sous forme de variables d’environnement ou de fichiers montés.

• Notes de sécurité
• En transit : TLS entre les composants.
• Au repos : activez le chiffrement au repos pour etcd; sinon les valeurs ne sont qu’encodées en base64.
• Contrôle d’accès : limitez strictement les droits RBAC pour réduire qui peut lire les Secrets.

Inventaire des versions et de l’environnement

Avant de changer quoi que ce soit, dressez l’inventaire de votre environnement et capturez l’état actuel. Les exemples ci-dessous fonctionnent avec Kubernetes 1.23–1.29 et kubectl.

• Confirmer les versions du cluster et du client

kubectl version --short
kubectl config current-context
kubectl get ns

• Choisir un espace de noms et le définir pour les commandes suivantes

NAMESPACE=secrets-lab
kubectl create namespace "$NAMESPACE" 2>/dev/null || true
kubectl config set-context --current --namespace="$NAMESPACE"

• Observation en lecture seule des Secrets et Pods

kubectl get secrets
kubectl get pods -o wide

• Vérifier la santé d’un déploiement avant de supposer qu’il a réussi

kubectl rollout status deployment/<name>

• Optionnel (plan de contrôle autogéré) : vérifier le chiffrement au repos
• Recherchez le paramètre kube-apiserver --encryption-provider-config et un fichier de configuration valide sur le nœud de plan de contrôle.
• Sur les clusters managés, consultez la documentation de votre fournisseur pour activer et vérifier le chiffrement au repos.

Gardez le périmètre de test initial réduit : appliquez un seul manifeste, observez les ressources générées et vérifiez depuis un seul Pod avant d’introduire de l’ingress ou des load balancers.

Chemin de configuration sûr (plus petit changement justifié)

Nous allons créer un Secret minimal, le consommer à la fois via des variables d’environnement et un volume, puis vérifier depuis l’intérieur d’un Pod. Utilisez des valeurs fictives — jamais de véritables identifiants — pendant les répétitions à blanc.

1. Créer un Secret à partir de valeurs littérales

cat <<'EOF' > secret-db.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  labels:
    app: demo
  # Définissez immutable: true lorsque vous êtes sûr des clés et des noms
# immutable: true
type: Opaque
stringData:
  username: demo_user
  password: demo_password
  url: postgres://db:5432/app
EOF

kubectl apply -f secret-db.yaml
kubectl get secret db-credentials -o yaml

Attendez-vous à voir des clés data (encodées en base64) ou des clés stringData (si l’API server renvoie l’objet tel que soumis; la forme stockée est data).

1. Déployer un Pod qui consomme le Secret

Cet exemple utilise un conteneur simple qui dort afin que vous puissiez y exécuter des commandes.

cat <<'EOF' > deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
      # Mettez à jour ce checksum lors d’une rotation de secrets pour forcer un déploiement
      annotations:
        secret-checksum: "$(date +%s)"
    spec:
      containers:
      - name: app
        image: alpine:3.19
        command: ["/bin/sh","-c","sleep 3600"]
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: username
        - name: DB_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: url
        volumeMounts:
        - name: db-secret
          mountPath: /etc/db
          readOnly: true
      volumes:
      - name: db-secret
        secret:
          secretName: db-credentials
EOF

kubectl apply -f deploy.yaml
kubectl rollout status deployment/demo-app

1. Vérifier depuis l’intérieur du Pod

POD=$(kubectl get pod -l app=demo -o jsonpath='{.items[0].metadata.name}')
# Vérifier les variables d’environnement
kubectl exec "$POD" -- sh -c 'echo "$DB_USER" && echo "$DB_URL"'
# Vérifier les fichiers montés
kubectl exec "$POD" -- ls -l /etc/db
kubectl exec "$POD" -- sh -c 'printf "username: "; cat /etc/db/username; echo; printf "url: "; cat /etc/db/url; echo'

Si un nom de clé est incorrect, le conteneur peut démarrer avec une variable d’environnement vide, ou le volume peut être monté sans la clé manquante. Nous aborderons le diagnostic ensuite.

Vérification et diagnostic

• Inspecter le contenu d’un Secret en toute sécurité (décodage local uniquement)

kubectl get secret db-credentials -o jsonpath='{.data.username}' | base64 -d; echo
kubectl get secret db-credentials -o jsonpath='{.data.url}' | base64 -d; echo

• Dépannage au niveau du Pod

kubectl get pods -o wide
kubectl describe pod "$POD"

Recherchez des événements tels que :

• CreateContainerConfigError: secret "db-credentials" not found
• Failed to pull image: sans lien, corrigez d’abord les images
• Back-off restarting failed container: consultez les logs de l’application

• Journaux et tentative précédente

kubectl logs "$POD" --previous 2>/dev/null || true

• Signaux de déploiement

kubectl rollout status deployment/demo-app
kubectl describe deployment demo-app | sed -n '/Events/,$p'

• Confirmer que les mises à jour prennent effet
• Les variables d’environnement sont figées au démarrage du conteneur. Après modification d’un Secret, redémarrez les Pods ou déclenchez un déploiement pour voir les nouvelles valeurs.
• Les volumes Secret montés se mettent à jour en quelques minutes sans redémarrage (rafraîchissement par le kubelet). Vérifiez en relisant les fichiers depuis le Pod en cours d’exécution.

Modes de défaillance et récupération

Problèmes courants et étapes concrètes pour les résoudre :

1. Secret introuvable

• Symptôme : un événement du Pod affiche CreateContainerConfigError: secret "..." not found.
• Vérification : kubectl get secret <name> dans l’espace de noms du Pod.
• Solution : créez le Secret ou mettez à jour le nom référencé; réappliquez le Deployment.

1. Nom de clé erroné

• Symptôme : variable d’environnement vide ou fichier manquant sous le chemin de montage.
• Vérification : listez les clés du Secret avec kubectl get secret <name> -o yaml.
• Solution : corrigez les noms de clés dans la spécification du Pod ou ajoutez la clé manquante au Secret.

1. La rotation ne s’est pas propagée

• Symptôme : le Pod utilise encore d’anciens identifiants.
• Raison : les variables d’environnement exigent un redémarrage; les fichiers montés peuvent prendre un léger retard.
• Solution : déclenchez un déploiement après la mise à jour du Secret :

kubectl apply -f secret-db.yaml
kubectl annotate deployment demo-app secret-checksum=$(date +%s) --overwrite
kubectl rollout status deployment/demo-app

1. Secret trop volumineux

• Symptôme : erreur de l’API au sujet de la limite de taille d’objet.
• Contexte : la taille d’un objet Kubernetes est plafonnée (environ 1 MiB). De gros paquets de certificats ou clés peuvent atteindre cette limite.
• Solution : stockez le contenu volumineux à l’extérieur (stockage objet ou gestionnaire de secrets externe) et montez-le via CSI ou un conteneur d’initialisation.

1. Modification accidentelle et dérive

• Symptôme : panne difficile à retracer après l’édition directe d’un Secret.
• Prévention : définissez immutable: true une fois les clés validées. Pour mettre à jour, supprimez puis recréez le Secret.
• Récupération : restaurez depuis un manifeste fiable ou une sauvegarde :

kubectl get secret db-credentials -o yaml > backup-secret.yaml   # à faire avant les changements
# En cas de problème, revenir en arrière :
kubectl apply -f backup-secret.yaml
kubectl rollout status deployment/demo-app

1. Accès excessif aux Secrets

• Symptôme : des développeurs ou des comptes de service peuvent lister tous les Secrets.
• Solution : resserrez le RBAC. Exemple : autoriser seulement get sur un Secret précis pour un compte de service :

cat <<'EOF' | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-db-secret
  namespace: secrets-lab
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["db-credentials"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-read-db-secret
  namespace: secrets-lab
subjects:
- kind: ServiceAccount
  name: default
  namespace: secrets-lab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: read-db-secret
EOF

Liste de contrôle opérationnelle (pratique et vérifiable)

À utiliser avant et après chaque changement :

• Observer d’abord
• Enregistrer la version du cluster, le contexte, l’espace de noms et les horodatages.
• kubectl get secrets, kubectl describe pods et kubectl rollout status pour établir la ligne de base.

• Cadrer et protéger
• Utilisez des valeurs fictives en développement; ne collez jamais de véritables identifiants dans des terminaux enregistrés par des outils de session.
• Gardez chaque changement minimal : un Secret ou un Deployment à la fois.

• Stocker et déployer
• Gérez les Secrets comme du code en utilisant stringData dans des manifestes conservés dans un dépôt privé, plus un mécanisme de scellement/modélisation (p. ex., sealed-secrets ou un opérateur) afin que le texte en clair n’atterrisse jamais dans l’historique Git.
• Étiquetez les Secrets (propriétaire, application, date de rotation) pour les retrouver facilement.

• Contrôle d’accès et chiffrement
• Appliquez le moindre privilège via RBAC : évitez les droits de liste au niveau cluster sur les secrets.
• Activez le chiffrement au repos pour etcd.
• Restreignez qui peut get ou watch les Secrets via les politiques Admission et RBAC.

• Modes de consommation
• Préférez les fichiers montés pour les valeurs qui changent sans redémarrage; n’utilisez des variables d’environnement que pour des valeurs figées au démarrage.
• Ajoutez une annotation de somme de contrôle aux Deployments qui consomment des Secrets via env pour forcer des rollouts déterministes lors des rotations.

• Rotation et récupération
• Faites tourner les identifiants selon un calendrier; scripttez les mises à jour et les déploiements.
• Conservez un retour arrière testé : un manifeste Secret antérieur et kubectl rollout undo pour les Deployments.

• Audit et visibilité
• Activez les journaux d’audit sur l’API server (autogéré) ou l’équivalent chez votre fournisseur.
• Interrogez périodiquement quels Pods référencent chaque Secret.

kubectl get pods -A -o json | jq -r '
  .items[] | {ns:.metadata.namespace, name:.metadata.name, secrets:(.spec.volumes // []) + [] | map(select(.secret!=null) | .secret.secretName)}
'

Au-delà des fonctions intégrées : gestionnaires externes (optionnel)

Pour les organisations standardisant sur un KMS/gestionnaire de secrets cloud ou sur site, intégrez-vous à Kubernetes via le Secrets Store CSI Driver ou un opérateur qui synchronise les secrets externes vers des objets Secret natifs. Flux de travail typique :

• Définir une référence (p. ex., SecretProviderClass) vers un chemin/clé dans le magasin externe.
• Monter le contenu comme un volume dans les Pods ou le synchroniser dans un Secret Kubernetes.
• Vérifier avec les mêmes contrôles via exec dans le Pod et surveiller les événements de rotation provenant du système externe.

Conservez les mêmes principes de sécurité : démarrez dans un espace de noms de test, observez, changez une seule chose, et confirmez le contenu du montage avant un déploiement plus large.

Conclusion

Les Secrets Kubernetes offrent une voie propre et traçable pour livrer la configuration sensible aux workloads, mais la sécurité opérationnelle dépend de la compréhension de leur circulation dans le système. Commencez par un test réduit et borné dans le temps : créez un Secret, référencez-le depuis un Deployment, vérifiez les variables d’environnement et les fichiers montés, et suivez l’état du déploiement. Diagnostiquez avec describe, les logs et les décodages jsonpath; récupérez avec des sauvegardes et des rollouts contrôlés. Appliquez le RBAC et activez le chiffrement au repos, préférez les volumes pour les valeurs changeantes, et utilisez des annotations pour déclencher des redémarrages déterministes lors des rotations d’identifiants. Avec ces étapes concrètes, vous pouvez déployer en confiance tout en réduisant l’exposition et le rayon d’impact.