ETCD Encryption

Définition

etcd est la base de données distribuée clé-valeur qui stocke l'état de tout le cluster Kubernetes : les définitions de pods, de services, de déploiements, les ConfigMaps, et surtout les Secrets Kubernetes. Par défaut dans Kubernetes, les Secrets sont stockés dans etcd encodés en base64 mais non chiffrés. L'activation du chiffrement au repos d'etcd (Encryption at Rest) est donc critique pour la protection des données sensibles dans un cluster Kubernetes. La configuration du chiffrement etcd se fait via un fichier EncryptionConfiguration appliqué au kube-apiserver via le flag --encryption-provider-config. Ce fichier liste les ressources à chiffrer et les algorithmes utilisés. Les ressources les plus critiques à chiffrer sont les Secrets, les ConfigMaps (si des données sensibles y sont stockées), et les ServiceAccounts. Les algorithmes supportés incluent : aescbc (AES-CBC, algorithme historique), aesgcm (AES-GCM, recommandé pour les nouvelles installations, meilleur pour les grandes charges), secretbox (XSalsa20 + Poly1305, résistant aux timing attacks), et kms (délégation du chiffrement à un KMS externe comme AWS KMS, Azure Key Vault, GCP Cloud KMS - recommandé pour la production). Le provider kms v2 (Kubernetes 1.29+) utilise une clé de chiffrement d'enveloppe générée par le KMS et renouvelée automatiquement. La migration vers le chiffrement etcd sur un cluster existant nécessite : 1) activer le chiffrement via EncryptionConfiguration, 2) réécrire toutes les ressources existantes pour qu'elles soient rechiffrées (kubectl get secrets --all-namespaces -o json | kubectl replace -f -). Sans cette étape de réécriture, les ressources existantes restent non chiffrées dans etcd jusqu'à leur prochaine modification. Dans les clusters managés (EKS, AKS, GKE), le chiffrement etcd est généralement activé par défaut ou proposé comme option lors de la création du cluster. EKS chiffre etcd avec des clés AWS KMS gérées par AWS, avec possibilité d'utiliser une CMK spécifique pour la conformité.