Publié le 25 septembre 2026 à 11:00 · Publication originale
Lorsqu'un administrateur l'affiche, il peut voir:
cGFzc3dvcmQ=
La chaîne paraît protégée. Elle ne l'est pas.
C'est du base64: un encodage réversible sans clé. Kubernetes le précise explicitement. Par défaut, les objets Secret sont aussi stockés sans chiffrement dans etcd, la base du plan de contrôle.
Le nom "Secret" décrit donc la nature de la donnée, pas automatiquement sa protection.
Kubernetes permet de chiffrer les ressources de l'API au repos. Avec KMS v2, les données sont protégées par des clés de chiffrement, elles-mêmes protégées par une clé gérée dans un KMS distant. Compromettre etcd ne suffit alors plus, à lui seul, pour retrouver le contenu en clair.
Mais une application doit finir par obtenir le secret pour l'utiliser. Dès qu'il est exposé dans un volume, une variable d'environnement ou accessible via l'API, les permissions deviennent décisives.
Kubernetes recommande ainsi de limiter fortement `get`, `list` et `watch`. Un composant autorisé à lister les Secrets peut disposer d'un pouvoir très supérieur à son rôle apparent.
ULTRA®
Le piège le plus intéressant apparaît lorsque le chiffrement est activé après coup.
Kubernetes chiffre les objets lorsqu'ils sont écrits. Modifier la configuration ne réécrit donc pas automatiquement les Secrets déjà présents dans etcd. Il faut les relire puis les réécrire pour appliquer la nouvelle protection.
La rotation obéit à la même logique: introduire la nouvelle clé, l'utiliser pour les nouvelles écritures, réécrire les anciennes données, puis retirer l'ancienne lorsque la migration est terminée.
C'est pourquoi "chiffrement activé" ne constitue pas encore une preuve suffisante.
Il faut vérifier ce qui est réellement stocké dans etcd.
La sécurité d'un secret dépend moins de son nom que de son chiffrement, de ses droits d'accès et de son état réel dans le stockage.
#VOCEASSOCIATION #Kubernetes #Cybersecurite #CloudSecurity