Kubernetes : chiffrer les données des Secrets au repos – checklist opérationnelle de production avec exemples pratiques

Introduction

Les Secrets Kubernetes sont le moyen standard de stocker des données sensibles telles que les mots de passe, les jetons d'API et les clés TLS. Par défaut, les Secrets sont stockés non chiffrés dans etcd, la base de données de sauvegarde du cluster. Toute personne ayant accès à etcd (ou à ses sauvegardes) peut les lire, ce qui représente un risque de sécurité sérieux. Le chiffrement des données des Secrets au repos est un contrôle essentiel pour les clusters de production.

Cet article fournit une checklist opérationnelle pratique pour activer et vérifier le chiffrement des Secrets Kubernetes au repos. Il s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent passer d'un problème observé à un résultat vérifié. L'accent est mis sur la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des valeurs fictives plutôt que de vrais secrets, vérifier le résultat et documenter les étapes de récupération.

Nous couvrirons l'inventaire des versions et de l'environnement, la configuration sûre du fichier de configuration de chiffrement du kube-apiserver, la vérification et le diagnostic, les modes de défaillance et la récupération, ainsi qu'une checklist opérationnelle concise. Chaque section comprend des commandes, les sorties attendues, les signaux de défaillance et les décisions de récupération.

Inventaire des versions et de l'environnement

Avant d'effectuer tout changement, vous devez comprendre la version de votre cluster et la configuration du serveur d'API. Le chiffrement au repos est configuré directement sur le kube-apiserver via le drapeau --encryption-provider-config. Ce n'est pas une ressource Kubernetes ; c'est un fichier statique que le serveur d'API lit au démarrage.

Identifier la version de Kubernetes et la configuration du serveur d'API

Exécutez la commande suivante pour vérifier la version du cluster :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.27.3
Server Version: v1.27.3

Le chiffrement au repos est pris en charge dans toutes les versions récentes de Kubernetes, mais le format de configuration a pu évoluer. L'API EncryptionConfiguration est versionnée : apiserver.config.k8s.io/v1 est stable depuis la version 1.13, et v1 est recommandée pour les clusters actuels. Vérifiez si votre serveur d'API a déjà le chiffrement configuré en examinant la spécification du pod (s'il fonctionne en pods statiques) ou les arguments du processus.

Pour un cluster kubeadm, le manifeste du serveur d'API se trouve généralement à /etc/kubernetes/manifests/kube-apiserver.yaml. Pour un cluster managé (EKS, GKE, AKS), vous n'aurez peut-être pas d'accès direct ; vous devez utiliser les mécanismes du fournisseur (par exemple, le fournisseur de chiffrement EKS, le chiffrement des secrets au niveau de l'application GKE).

Pour voir la ligne de commande du serveur d'API dans un cluster en cours d'exécution, utilisez :

kubectl -n kube-system get pod kube-apiserver-<nom-du-nœud> -o jsonpath='{.spec.containers[0].command}'

Recherchez --encryption-provider-config. S'il est absent, le chiffrement n'est pas activé.

Prérequis

Vous avez besoin des autorisations cluster-admin pour modifier la configuration du serveur d'API et le redémarrer.
Assurez-vous d'avoir accès aux nœuds du plan de contrôle ou la possibilité de mettre à jour les paramètres du serveur d'API dans votre environnement managé.
Sauvegardez le manifeste existant du serveur d'API ou la configuration avant toute modification.
Ayez un environnement de test local (par exemple, kind ou minikube) pour pratiquer la procédure en toute sécurité.

Observation en lecture seule

Vérifiez l'état actuel du chiffrement en créant un Secret de test et en inspectant etcd directement (si possible) ou en utilisant un conteneur de débogage. Par exemple, créez un Secret :

kubectl create secret generic mon-secret --from-literal=key=supersecret

Ensuite, si vous avez accès à etcd, vous pouvez l'interroger (dans un cluster kubeadm, etcd fonctionne comme un pod statique) :

ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get /registry/secrets/default/mon-secret

Sortie attendue si non chiffré : vous verrez la chaîne littérale supersecret dans la sortie, prouvant que les données sont stockées en clair.

Si vous ne pouvez pas accéder à etcd, vous pouvez inspecter les journaux du serveur d'API pour détecter des erreurs de chiffrement. Utilisez kubectl logs -n kube-system kube-apiserver-<nom-du-nœud> | grep -i encrypt pour voir si le chiffrement est actif.

Plus petit changement justifié

Le plus petit changement pour activer le chiffrement est de créer un fichier EncryptionConfiguration et d'ajouter le drapeau --encryption-provider-config au serveur d'API. Cependant, l'activation du chiffrement ne rechiffre pas rétroactivement les Secrets existants. Vous devez réécrire tous les Secrets pour déclencher le chiffrement, ce que nous verrons plus tard.

Vérifier le résultat

Après avoir activé le chiffrement et redémarré le serveur d'API, créez un nouveau Secret et répétez l'inspection etcd. Vous devriez voir les données préfixées par k8s:enc:aescbc:v1: (si vous utilisez AES-CBC) ou un autre préfixe de fournisseur, et aucun texte en clair.

Vérification pratique Kubernetes pour l'inventaire des versions et de l'environnement :

Commencez par kubectl get pods -n kube-system -o wide pour voir les pods du plan de contrôle.
Utilisez kubectl describe pod -n kube-system kube-apiserver-<nom-du-nœud> pour examiner les événements et les montages.
Vérifiez kubectl logs -n kube-system kube-apiserver-<nom-du-nœud> --previous pour les détails de boucle de crash.
Exécutez kubectl get events --all-namespaces --sort-by=.metadata.creationTimestamp pour voir les problèmes récents.

Gardez toujours un test local petit. Appliquez un seul manifeste, inspectez les ressources générées et vérifiez avec kubectl port-forward ou un type de service local avant de passer à un équilibreur de charge cloud ou à un contrôleur d'entrée.

Question rapide 1 sur 2

Selon le texte, quel est l'objectif principal des Secrets Kubernetes ?

Le texte indique : « Les Secrets Kubernetes sont le moyen standard de stocker des données sensibles telles que des mots de passe, des jetons API et des clés TLS. »

Chemin de configuration sûr

Maintenant que vous avez inventorié l'environnement, vous pouvez configurer en toute sécurité le chiffrement au repos. Les étapes clés sont :

Choisir un fournisseur de chiffrement (par exemple, AES-CBC, AES-GCM, KMS).
Créer le fichier EncryptionConfiguration.
Mettre à jour le manifeste du serveur d'API pour le référencer.
Redémarrer le serveur d'API et vérifier qu'il démarre correctement.
Réécrire tous les Secrets existants pour s'assurer qu'ils sont chiffrés.

Choisir un fournisseur de chiffrement

Kubernetes prend en charge plusieurs fournisseurs :

aescbc : Recommandé pour le chiffrement au repos. Utilise AES-CBC avec remplissage PKCS#7. Nécessite une clé de 32 octets.
aesgcm : Utilise AES-GCM. Remarque : GCM est non déterministe, et etcd ne prend pas en charge la surveillance sur le chiffrement non déterministe dans les anciennes versions. Préférez aescbc pour la compatibilité etcd.
secretbox : Utilise XSalsa20 et Poly1305. Également acceptable mais moins courant.
kms : Utilise un service de gestion de clés externe (par exemple, AWS KMS, GCP KMS, Azure Key Vault). Recommandé pour la production car les clés sont gérées en externe et peuvent être tournées.

Pour cette checklist, nous utiliserons aescbc comme exemple car il est simple et largement pris en charge. En production, envisagez d'utiliser un fournisseur KMS pour une meilleure gestion des clés.

Créer le fichier EncryptionConfiguration

Créez un fichier nommé encryption-config.yaml avec le contenu suivant :

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <clé-32-octets-encodée-en-base64>
      - identity: {}

Vous devez générer une clé aléatoire de 32 octets et l'encoder en base64. Exemple :

head -c 32 /dev/urandom | base64

Sortie attendue : une chaîne base64 de 44 caractères se terminant par =, par exemple, dGhpcyBpcyBhIDMyIGJ5dGUga2V5IGZvciBkZW1vbmQ= (ceci est un exemple ; générez la vôtre).

Remplacez <clé-32-octets-encodée-en-base64> par votre clé générée. Le fournisseur identity: {} comme deuxième entrée permet la lecture des Secrets existants non chiffrés pendant la migration. Une fois tous les Secrets chiffrés, vous pouvez supprimer le fournisseur identity pour une sécurité plus stricte.

Mettre à jour le manifeste du serveur d'API

Si vous utilisez kubeadm, modifiez le fichier manifeste sur le nœud du plan de contrôle :

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Ajoutez ce qui suit au tableau spec.containers[0].command :

- --encryption-provider-config=/etc/kubernetes/encryption-config.yaml

Ajoutez également un montage de volume et un volume :

Sous volumeMounts :

- name: encryption-config
  mountPath: /etc/kubernetes/encryption-config.yaml
  readOnly: true

Sous volumes :

- name: encryption-config
  hostPath:
    path: /etc/kubernetes/encryption-config.yaml
    type: File

Placez le fichier encryption-config.yaml sur le nœud du plan de contrôle à /etc/kubernetes/encryption-config.yaml avec les permissions 600 et le propriétaire root.

Pour les clusters haute disponibilité avec plusieurs nœuds du plan de contrôle, vous devez copier le fichier sur tous les nœuds et mettre à jour chaque manifeste.

Redémarrer le serveur d'API

Le kubelet redémarrera automatiquement le serveur d'API lorsque le manifeste changera. Surveillez le redémarrage :

kubectl get pods -n kube-system -w

Attendez que le nouveau pod du serveur d'API soit en cours d'exécution et prêt. Vérifiez les journaux pour les messages liés au chiffrement :

kubectl logs -n kube-system kube-apiserver-<nom-du-nœud> | grep -i encryption

Sortie attendue : aucune erreur. Si vous voyez des erreurs comme « invalid encryption config » ou « failed to load encryption config », vérifiez les permissions du fichier et son contenu.

Vérifier que les nouveaux Secrets sont chiffrés

Créez un nouveau Secret :

kubectl create secret generic test-chiffrement --from-literal=key=valeur123

Inspectez à nouveau etcd (comme montré précédemment). Vous devriez voir la forme chiffrée avec le préfixe k8s:enc:aescbc:v1:key1: et aucun texte en clair.

Réécrire tous les Secrets existants

Les Secrets existants ne sont pas automatiquement rechiffrés. Vous devez les mettre à jour pour déclencher la réécriture. Utilisez cette commande :

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Cette commande lit tous les Secrets et les remplace avec les mêmes données, ce qui amène le serveur d'API à les rechiffrer en utilisant le nouveau fournisseur. Soyez prudent : cela écrasera tous les champs qui ne sont pas dans l'objet actuel, mais pour les Secrets, c'est sûr car les données sont préservées.

Après la réécriture, vérifiez qu'un Secret existant précédemment est maintenant chiffré dans etcd.

Vérification pratique Kubernetes pour le chemin de configuration sûr :

Utilisez kubectl get events -n kube-system --watch pendant le redémarrage du serveur d'API pour détecter les échecs.
Si le serveur d'API ne démarre pas, revenez en arrière en supprimant le drapeau et le volume ajoutés, puis redémarrez.
Gardez une sauvegarde du manifeste d'origine et du fichier de configuration de chiffrement.
Utilisez kubectl rollout status pour tous les déploiements qui dépendent des Secrets pour vous assurer qu'ils fonctionnent toujours.

Vérification et diagnostic

Après avoir activé le chiffrement, vous devez vérifier qu'il fonctionne correctement et diagnostiquer tout problème. Cette section fournit une approche systématique.

Vérifier la configuration du serveur d'API

Vérifiez que le serveur d'API utilise la configuration de chiffrement :

kubectl -n kube-system get pod kube-apiserver-<nom-du-nœud> -o yaml | grep -A5 -B5 encryption-provider-config

Sortie attendue : le drapeau apparaît dans la commande.

Valider le fichier de configuration de chiffrement

Vous pouvez utiliser kube-apiserver avec le drapeau --encryption-provider-config et une simulation pour valider le fichier sans affecter le cluster en cours d'exécution :

kube-apiserver --encryption-provider-config=/chemin/vers/encryption-config.yaml --dry-run

Cela peut nécessiter des drapeaux supplémentaires pour éviter les erreurs de connexion, mais cela peut aider à détecter un YAML malformé ou des noms de fournisseurs invalides.

Tester le chiffrement des nouveaux Secrets

Comme décrit, créez un Secret de test et inspectez etcd. Vous pouvez également utiliser les journaux d'audit du serveur d'API pour confirmer les opérations de chiffrement. Si la journalisation d'audit est activée, recherchez les actions encrypt ou decrypt.

S'assurer que les Secrets existants sont chiffrés

Après avoir réécrit tous les Secrets, vous devez vérifier qu'aucun ne reste en clair. Vous pouvez interroger etcd pour tous les secrets et rechercher l'absence de valeurs en clair. Par exemple, obtenez toutes les clés sous /registry/secrets/ et recherchez les chaînes en clair connues.

Si vous avez stocké le texte en clair avant le chiffrement, comparez maintenant.

Diagnostic : le serveur d'API ne démarre pas

Si le pod du serveur d'API est en CrashLoopBackOff, vérifiez les journaux :

kubectl logs -n kube-system kube-apiserver-<nom-du-nœud> --previous

Recherchez des lignes comme :

F0710 12:00:00.000000 1 server.go:123] error loading encryption provider config: ...

Cela indique un problème avec le fichier de configuration. Problèmes courants :

Fichier introuvable au chemin de montage.
Syntaxe YAML ou version d'API incorrecte.
Longueur de clé base64 invalide (doit décoder en 32 octets pour aescbc).
Permission refusée sur le fichier.

Corrigez le problème, enregistrez le fichier, et le serveur d'API devrait redémarrer automatiquement.

Diagnostic : les Secrets existants ne sont pas chiffrés après la réécriture

Si après avoir exécuté la commande de réécriture, etcd montre toujours du texte en clair pour certains Secrets, vérifiez la configuration de chiffrement. Le fournisseur identity pourrait être en premier dans la liste, ou la liste des ressources pourrait manquer secrets. Vérifiez l'ordre : les fournisseurs sont essayés dans l'ordre, et le premier fournisseur qui peut chiffrer est utilisé. Pour la lecture, le serveur d'API essaie les fournisseurs jusqu'à ce que l'un réussisse. Si identity est en premier, les nouvelles écritures seront non chiffrées.

Vérification pratique Kubernetes pour la vérification et le diagnostic :

Exécutez kubectl get secrets --all-namespaces | wc -l avant et après la réécriture pour vous assurer que le nombre est cohérent.
Utilisez kubectl get secret <nom> -o yaml pour comparer les données (encodées en base64) avant et après ; elles doivent être identiques.
Surveillez les métriques du serveur d'API si elles sont activées : apiserver_storage_transformation_operations_total et apiserver_storage_transformation_duration_seconds.
Vérifiez les métriques etcd pour les erreurs liées au chiffrement.

Modes de défaillance et récupération

Cette section couvre les scénarios de défaillance courants et comment s'en remettre.

Défaillance : le serveur d'API ne démarre pas en raison d'une configuration de chiffrement invalide

Symptôme : Le pod du serveur d'API est en CrashLoopBackOff, le cluster est inaccessible via kubectl.

Récupération :

Connectez-vous en SSH au nœud du plan de contrôle.
Modifiez le manifeste du serveur d'API (/etc/kubernetes/manifests/kube-apiserver.yaml) et supprimez le drapeau --encryption-provider-config ainsi que le montage/volume.
Enregistrez le fichier ; le kubelet redémarrera le serveur d'API sans chiffrement.
Une fois le cluster accessible, corrigez le fichier de configuration de chiffrement.
Rajoutez le drapeau et le volume, puis enregistrez à nouveau.

Ayez toujours une sauvegarde du manifeste avant de faire des modifications.

Défaillance : impossible de déchiffrer les Secrets après rotation des clés

Si vous faites tourner les clés de chiffrement en ajoutant une nouvelle clé en haut de la liste keys, l'ancienne clé doit rester dans la liste pour que les Secrets existants puissent être déchiffrés. Si vous supprimez l'ancienne clé, le serveur d'API ne peut pas déchiffrer les Secrets précédemment chiffrés, ce qui entraîne des échecs lors de leur lecture.

Récupération : Restaurez la clé précédente dans la liste des clés, redémarrez le serveur d'API, puis effectuez correctement la rotation des clés :

Ajoutez la nouvelle clé comme première entrée, gardez l'ancienne clé comme deuxième.
Redémarrez le serveur d'API.
Réécrivez tous les Secrets (kubectl get secrets --all-namespaces -o json | kubectl replace -f -).
Vérifiez que tous les Secrets sont chiffrés avec la nouvelle clé (vous pouvez vérifier le préfixe dans etcd, qui inclut le nom de la clé).
Supprimez l'ancienne clé de la configuration et redémarrez le serveur d'API.

Défaillance : perte du fichier de configuration de chiffrement

Si le fichier de configuration de chiffrement est perdu (par exemple, défaillance du disque du nœud du plan de contrôle) et que vous n'avez pas de sauvegarde, tous les Secrets chiffrés avec cette clé sont irrécupérables. C'est pourquoi les fournisseurs KMS sont recommandés : ils stockent les clés en externe.

Prévention : Sauvegardez toujours le fichier de configuration de chiffrement et les clés dans un endroit sécurisé. Stockez des copies dans un gestionnaire de secrets ou hors ligne.

Défaillance : dégradation des performances du serveur d'API

Le chiffrement ajoute une surcharge CPU aux requêtes du serveur d'API qui impliquent des Secrets. Pour les clusters à fort trafic, cela pourrait augmenter la latence. Surveillez l'utilisation des ressources du serveur d'API et envisagez d'utiliser KMS avec un chiffrement matériel ou un fournisseur plus efficace. Si les performances sont inacceptables, vous devrez peut-être faire évoluer le serveur d'API ou réduire la fréquence de lecture/écriture des Secrets.

Défaillance : réécriture incomplète des Secrets

Si la commande de réécriture est interrompue (par exemple, problème de réseau), certains Secrets peuvent rester non chiffrés. Exécutez à nouveau la commande de réécriture ; elle est idempotente. Pour garantir un chiffrement complet, supprimez le fournisseur identity de la configuration après la réécriture. Sans identity, le serveur d'API n'autorisera que la lecture des Secrets chiffrés, donc s'il reste du texte en clair, ces Secrets échoueront à la lecture, révélant le problème.

Récupération : Si vous avez supprimé identity et que certains Secrets sont illisibles, rajoutez temporairement identity, réécrivez tous les Secrets à nouveau, puis supprimez-le.

Vérification pratique Kubernetes pour les modes de défaillance et la récupération :

Avant tout changement, prenez un instantané etcd si possible : ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db.
Testez la procédure de retour en arrière dans un cluster de préproduction.
Documentez les étapes exactes pour votre environnement, y compris les spécificités du service managé.
Utilisez kubectl get secrets --all-namespaces -o json > secrets-backup.json pour avoir une sauvegarde de tous les Secrets (mais notez que cette sauvegarde contient des données en clair dans le JSON ; stockez-la de manière sécurisée).

Checklist opérationnelle

Voici une checklist concise pour activer et gérer le chiffrement des Secrets au repos en production.

Checklist pré-changement

[ ] Vérifier la version de Kubernetes et la configuration du serveur d'API.
[ ] Confirmer l'accès cluster-admin et l'accès au nœud du plan de contrôle (si auto-géré).
[ ] Sauvegarder le manifeste du serveur d'API et le fichier de configuration de chiffrement (s'il existe).
[ ] Prendre un instantané etcd ou une sauvegarde de tous les Secrets.
[ ] Générer une nouvelle clé aléatoire de 32 octets et l'encoder en base64 de manière sécurisée.
[ ] Créer le fichier EncryptionConfiguration avec aescbc (ou le fournisseur choisi) et identity comme secondaire.
[ ] Copier le fichier sur tous les nœuds du plan de contrôle avec les permissions correctes (600).
[ ] Tester dans un cluster de préproduction.

Checklist d'exécution du changement

[ ] Mettre à jour le manifeste du serveur d'API sur tous les nœuds du plan de contrôle pour ajouter --encryption-provider-config et le montage de volume.
[ ] Surveiller les pods du serveur d'API pour un redémarrage réussi.
[ ] Vérifier que les journaux du serveur d'API ne montrent aucune erreur de chiffrement.
[ ] Créer un Secret de test et confirmer qu'il est chiffré dans etcd.
[ ] Exécuter kubectl get secrets --all-namespaces -o json | kubectl replace -f - pour réécrire tous les Secrets.
[ ] Vérifier qu'un échantillon de Secrets existants est maintenant chiffré.

Checklist de vérification post-changement

[ ] Vérifier les métriques du serveur d'API pour les opérations de chiffrement.
[ ] Exécuter un test de lecture/écriture pour les Secrets dans un espace de noms de test.
[ ] Confirmer que les applications qui utilisent des Secrets fonctionnent.
[ ] Supprimer le fournisseur identity de la configuration (après s'être assuré que tous les Secrets sont chiffrés).
[ ] Redémarrer le serveur d'API avec la configuration mise à jour (sans identity).
[ ] Re-vérifier que les Secrets sont lisibles et que les nouveaux Secrets sont chiffrés.
[ ] Documenter le nouvel identifiant de clé et le calendrier de rotation.

Maintenance continue

[ ] Faire tourner périodiquement les clés de chiffrement (au moins tous les 90 jours ou selon la politique).
[ ] Garder le fichier de configuration de chiffrement et les clés dans un endroit sécurisé et sauvegardé.
[ ] Surveiller les performances du serveur d'API et les journaux d'erreurs pour les problèmes de chiffrement.
[ ] Mettre à jour les procédures pour la perte de clé, le retour en arrière et la reprise après sinistre.

Conclusion

Le chiffrement des Secrets Kubernetes au repos est une mesure de sécurité essentielle pour les clusters de production. Le processus ne consiste pas seulement à activer un drapeau ; il nécessite une planification, une exécution et une vérification minutieuses pour éviter la perte de données ou les temps d'arrêt.

Cette checklist a parcouru l'inventaire de l'environnement, la configuration sûre, la vérification, les modes de défaillance et une checklist opérationnelle étape par étape. En suivant ces étapes, vous pouvez vous assurer que vos Secrets sont protégés contre l'accès non autorisé à etcd et à ses sauvegardes.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit une vérification de récupération avant qu'un incident ne force la décision. Commencez par une vérification à faible risque : créez un Secret de test, activez le chiffrement dans un cluster de préproduction et pratiquez le retour en arrière. Ensuite, passez en production en toute confiance.

Prochaines étapes : implémentez la checklist dans votre environnement, intégrez la rotation des clés dans votre politique de gestion des clés et envisagez d'utiliser un fournisseur KMS pour une sécurité renforcée et une gestion externe des clés.