Sauvegarde et restauration des Secrets Kubernetes avec exemples pratiques

Introduction

Les Secrets Kubernetes contiennent des identifiants, clés API, tokens, certificats et clés TLS, ainsi que d'autres valeurs critiques. La sauvegarde et la restauration de ces Secrets sont indispensables à toute stratégie de reprise après sinistre, mais restent trop souvent implicites... jusqu'à l'incident. Ce guide pratique vous montre comment :

Inventorier et cadrer un pilote sûr pour la sauvegarde des Secrets
Exporter des Secrets avec des manifests minimaux et réutilisables
Chiffrer et stocker les sauvegardes
Restaurer proprement dans un namespace ou un nouveau cluster
Vérifier la justesse avec des contrôles observables
Reconnaître les modes d'échec et récupérer de manière prédictible
Opérer avec une checklist reproductible

Les exemples supposent un shell Unix-like et un accès kubectl. Les noms et valeurs utilisés sont fictifs pour la clarté.

Inventaire des versions et de l'environnement

Prérequis :

Kubernetes : v1.19+ recommandé (Secrets immuables). Toute version maintenue convient.
kubectl : idéalement aligné sur la version mineure du cluster.
Accès : droits get/list/watch/create/patch/delete sur les Secrets des namespaces cibles (list cluster-wide pour une sauvegarde globale).
Outils optionnels : jq, yq, openssl, sops/age (chiffrement au repos des sauvegardes).
Périmètre pilote restreint : un namespace et 1-3 Secrets critiques, facilement auditables.

Commandes d'inventaire (lecture seule) :

kubectl version --short
kubectl config get-contexts
kubectl auth can-i list secrets -A
kubectl get ns

Notez le namespace cible et les Secrets du pilote, par ex. : demo, ai-api, app-tls.

Chemin de configuration sûr

Adoptez une voie simple et extensible : export kubectl avec métadonnées minimales, chiffrement au repos optionnel, restauration directe via manifests. Vous pourrez ensuite intégrer votre gestion de clés, GitLab CI/CD ou autres automatisations.

Décider quoi sauvegarder et quoi ignorer

Opaque (clés API, identifiants DB) : à inclure
kubernetes.io/tls : à inclure (vérifier l'expiration au moment de la restauration)
kubernetes.io/dockerconfigjson : à inclure (pull d'images privées)
Tokens de compte de service (anciens) : généralement non (éphémères en 1.24+) ; recréez via ServiceAccount
Jetons générés/très court terme : généralement non ; préférez la régénération

Identifier les Secrets cibles (pilote)

Lister les Secrets et leurs types dans demo :

kubectl get secrets -n demo -o custom-columns=NAME:.metadata.name, TYPE:.type

Exclure les tokens de comptes de service :

kubectl get secrets -n demo -o json \
  | jq -r '.items[] | select(.type!="kubernetes.io/service-account-token") \
  | [.metadata.name,.type] | @tsv'

Choisissez 1-3 Secrets : par ex. ai-api (Opaque) et app-tls (kubernetes.io/tls).

Exporter un Secret avec métadonnées minimales

Export JSON puis suppression des champs volatils :

kubectl get secret ai-api -n demo -o json \
  | jq 'del(.metadata.uid, .metadata.resourceVersion, .metadata.creationTimestamp, \
           .metadata.managedFields, \
           .metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"], \
           .metadata.generation)' \
  > ai-api.json

Conversion optionnelle en YAML :

yq -P e ai-api.json > ai-api.yaml

Exemple de YAML minimal (valeurs fictives) :

apiVersion: v1
kind: Secret
metadata:
  name: ai-api
  namespace: demo
type: Opaque
data:
  OPENAI_API_KEY: c2stdGVzdC1BQUFCQ0QxMjM0NTY=

Attention : les valeurs .data sont encodées en base64, pas chiffrées. Traitez ces fichiers comme sensibles (permissions strictes).

Exporter des Secrets TLS

Un Secret TLS doit avoir le type kubernetes.io/tls, avec tls.crt et tls.key :

kubectl get secret app-tls -n demo -o json \
  | jq 'del(.metadata.uid, .metadata.resourceVersion, .metadata.creationTimestamp, \
           .metadata.managedFields, \
           .metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"], \
           .metadata.generation)' \
  > app-tls.json

yq -P e app-tls.json > app-tls.yaml

Export en lot pour un namespace

Créer un fichier par Secret facilite les diffs et les restaurations :

NS=demo; TS=$(date +%Y%m%d-%H%M%S); mkdir -p backups/$NS-$TS
for s in $(kubectl get secrets -n $NS -o jsonpath='{.items[*].metadata.name}'); do
  kubectl get secret "$s" -n $NS -o json \
  | jq 'select(.type != "kubernetes.io/service-account-token")
         | del(.metadata.uid, .metadata.resourceVersion, .metadata.creationTimestamp,
               .metadata.managedFields,
               .metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"],
               .metadata.generation)' \
  > backups/$NS-$TS/$s.json;
  yq -P e backups/$NS-$TS/$s.json > backups/$NS-$TS/$s.yaml;
  rm backups/$NS-$TS/$s.json;
done

Ajustez les filtres selon votre environnement.

Optionnel : chiffrer les sauvegardes au repos

Chiffrez fichier par fichier avec sops et age :

age-keygen -o ~/.age/key.txt
sops --encrypt --age YOUR_AGE_PUBLIC_KEY backups/demo-20260101-000000/ai-api.yaml \
  > backups/demo-20260101-000000/ai-api.enc.yaml
sops --decrypt backups/demo-20260101-000000/ai-api.enc.yaml > /tmp/ai-api.yaml

Appliquez des permissions strictes (par ex. chmod 600) aux clés et sauvegardes.

Restaurer un Secret (même cluster ou nouveau cluster)

Vérifier/créer le namespace :

kubectl get ns demo || kubectl create ns demo

Appliquer le manifest :

kubectl apply -f ai-api.yaml

Gérer l'immutabilité si nécessaire :

kubectl get secret ai-api -n demo -o jsonpath='{.immutable}' 2>/dev/null || true
# Si immutable est true :
kubectl delete secret ai-api -n demo
kubectl apply -f ai-api.yaml

TLS :

kubectl apply -f app-tls.yaml

Redémarrer les workloads consommateurs d'env vars (non rechargées automatiquement) :

kubectl rollout restart deploy/myapp -n demo

Restaurer plusieurs Secrets

Si vous avez exporté un dossier par namespace :

kubectl apply -f backups/demo-20260101-000000/

Supprimez au préalable les Secrets immuables dont les valeurs ont changé, ou retirez immutable: true du fichier, supprimez, puis appliquez.

Vérification et diagnostics

Vérifier les fichiers de sauvegarde localement

Métadonnées et type :

yq e '.kind, .metadata.name, .metadata.namespace, .type' ai-api.yaml

Clés attendues (ex. OPENAI_API_KEY) :

yq e '.data | keys' ai-api.yaml

Empreinte hors cluster (stockez les sorties en lieu sûr) :

yq -r '.data.OPENAI_API_KEY' ai-api.yaml | base64 -d | sha256sum

Vérifier le Secret restauré en cluster

Présence et type :

kubectl get secret ai-api -n demo -o jsonpath='{.type}{"\n"}'

Jeu de clés + empreintes :

kubectl get secret ai-api -n demo -o json \
  | jq -r '.data | to_entries[] | "\(.key) \(.value)"' \
  | while read k v; do echo -n "$k "; echo -n "$v" | base64 -d | sha256sum; done

TLS : sujet et dates :

kubectl get secret app-tls -n demo -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > /tmp/tls.crt
openssl x509 -in /tmp/tls.crt -noout -subject -dates -fingerprint -sha256

Attendus : types identiques, mêmes clés, mêmes hachages si inchangés, et certificat TLS au sujet/dates prévus.

Vérifier la consommation par les workloads

Volumes montés :

kubectl exec -n demo deploy/myapp -- sh -c 'ls -l /etc/secrets && head -c 16 /etc/secrets/some-key | wc -c'

Env vars depuis Secrets : privilégiez des vérifications indirectes (ne pas imprimer les secrets). Vérifiez aussi :

kubectl rollout status deploy/myapp -n demo --timeout=120s

Diagnostics courants

Permissions :

kubectl auth can-i create secrets -n demo

Namespace erroné :

kubectl get secret ai-api -A | grep ai-api

Mauvais contexte :

kubectl config current-context

Événements liés aux Secrets :

kubectl get events -n demo --sort-by=.lastTimestamp | grep -i secret || true

Modes de défaillance et reprise

Namespace manquant : créer puis réappliquer.
Secret immuable modifié : supprimer puis recréer.
Type incohérent : assurer la correspondance de .type ; delete + recreate si besoin.
Données corrompues/non-base64 : repartir d'une sauvegarde saine ; vérifier l'encodage et les clés.
Export incomplet (métadonnées seules) : réexporter en s'assurant de .data ; valider avant restauration.
Mauvais cluster/contexte : vérifier le contexte kubectl ; étiqueter les sauvegardes avec l'ID cluster.
Workloads ne rechargent pas les env vars : rollout restart des déploiements/statefulsets.

Risques additionnels :

Fuite de stockage : chiffrement au repos et permissions strictes.
Sauvegardes trop larges : commencer par un pilote de namespace, élargir progressivement.
Dérive d'expiration TLS : vérifier la validité au restore pour éviter une panne immédiate.

Scénarios de reprise après sinistre

Restauration vers un nouveau cluster après perte

Recréer les namespaces
Appliquer les manifests de Secrets (priorité : pull d'images, creds appli, TLS)
Restaurer ConfigMaps et workloads
Déclencher les rollouts et vérifier la santé bout en bout

Rollback d'un Secret vers une version antérieure

Identifier le fichier horodaté
Si immutable : supprimer le Secret courant
Appliquer l'ancienne version
Redémarrer les workloads consommateurs d'env vars et valider

Perte partielle d'un namespace

Identifier les Secrets manquants en comparant inventaire vs cluster :

comm -23 <(ls backups/demo-20260101-000000 | sed 's/.yaml$//' | sort) \
  <(kubectl get secrets -n demo -o jsonpath='{.items[*].metadata.name}' | tr ' ' '\n' | sort)

Appliquer uniquement les Secrets manquants

Checklist d'exploitation

Quotidien ou à chaque changement :

Vérifier le contexte kubectl et le namespace cible
Exporter les Secrets modifiés avec métadonnées minimales
Chiffrer et stocker avec permissions restreintes

Hebdomadaire :

Tester une restauration dans un namespace non-prod
Vérifier les hachages et, pour TLS, la validité du certificat
Confirmer le rechargement côté workloads (volume vs env var)

Mensuel ou trimestriel :

Auditer l'RBAC (lecture/sauvegarde de Secrets)
Faire tourner les clés de chiffrement si politique requise
Réviser l'inventaire et adapter le périmètre de sauvegarde

Avant une restauration en production :

Valider l'existence et la justesse du namespace cible
Confirmer .type et clés attendues dans le manifest
Pour les Secrets immuables, planifier la fenêtre delete-then-apply et les rollouts

Après restauration :

Vérifier présence, type et empreintes des données
Redémarrer les consommateurs d'env vars et confirmer les rollouts
Contrôler la santé applicative et les logs (creds/TLS)
Documenter quoi, quand, et par qui

Exemples pratiques

Exemple 1 : sauvegarder et restaurer un Secret de clé API

Création et sauvegarde

Secret : ai-api, namespace : demo, type : Opaque
Export minimal vers ai-api.yaml
Chiffrement optionnel vers ai-api.enc.yaml

Restauration

sops --decrypt ai-api.enc.yaml > /tmp/ai-api.yaml
kubectl apply -f /tmp/ai-api.yaml

Vérifier l'empreinte vs sauvegarde
Redémarrer le déploiement :

kubectl rollout restart deploy/myapp -n demo

Exemple 2 : sauvegarder et restaurer un Secret TLS

Sauvegarde d'app-tls

Export minimal vers app-tls.yaml
Option : stocker tls.crt décodé pour openssl (sécurisé)

Restauration

kubectl apply -f app-tls.yaml
kubectl get secret app-tls -n demo -o jsonpath='{.data.tls\.crt}' | base64 -d > /tmp/tls.crt
openssl x509 -in /tmp/tls.crt -noout -subject -dates -fingerprint -sha256

Confirmer que l'ingress/service reprend des handshakes TLS sains

Conclusion

Une procédure fiable de sauvegarde et restauration des Secrets Kubernetes doit être simple, testable et observable. Démarrez avec un pilote restreint (un namespace, deux Secrets), exportez des manifests minimaux, chiffrez au repos, puis entraînez-vous régulièrement à restaurer avec des étapes de validation explicites. En étendant au-delà du pilote, formalisez la checklist, étiquetez et versionnez vos sauvegardes, et répétez les scénarios de reprise après sinistre. Quand la restauration est une opération claire, vérifiable et répétable, vous réduisez les retours arrière coûteux et accélérez la reprise. Prochaine étape : choisissez un namespace, sélectionnez deux Secrets, et réalisez un cycle complet sauvegarde-validation-restauration dès aujourd'hui.