Le Secret répond à une question d’hygiène, pas à une question de cryptographie. On y met ce qui, publié par accident, ferait mal : mot de passe, jeton, certificat. On ne le commite pas, on ne le grave pas dans l’image, on ne le range pas à côté de BG_COLOR dans un ConfigMap. Ça, il le protège : la séparation, le RBAC plus strict souvent appliqué, le montage en fichiers plutôt qu’en clair dans kubectl describe du Pod si l’on est soigneux.
Il n’est pas chiffré au repos par défaut. La valeur dans etcd est du base64. Base64 n’est pas un chiffrement, c’est un encodage. Quiconque peut kubectl get secret -o yaml lit le secret. Quiconque lit etcd sans encryption provider aussi.
Il ne protège pas contre :
get / list / watch sur secrets) ;Vault, un external secrets operator, SOPS, un KMS : ils alimentent le Secret ou le remplacent à l’injection. Ils ne rendent pas l’objet API magiquement sûr si tout le monde peut le lire. Le Secret reste souvent le point de livraison au Pod — volume, variable, CSI — pas le système de vérité.
Que vous ne dites pas « c’est chiffré, donc c’est bon ». La réponse senior tient en une pile : RBAC étroit, chiffrement etcd (EncryptionConfiguration au apiserver), pas de Secret dans Git (Sealed Secrets, SOPS, CI qui pousse depuis le coffre), rotation, et une appli qui ne logue pas ce qu’on lui a donné.
« Pourquoi ne pas tout mettre dans Vault et supprimer les Secrets ? »
Parce que le kubelet et la plupart des runtimes s’attendent à un Secret ou à un volume CSI. Vault sans opérateur, c’est chaque appli qui parle à Vault avec son propre identifiant — un autre secret, au démarrage. L’architecture habituelle : Vault (ou le gestionnaire cloud) est la source, le Secret Kubernetes est éphémère et scopé, et on surveille qui peut le lire.
Le détail de la frontière ConfigMap / Secret / Vault est dans Secret : ni ConfigMap, ni Vault, ni chiffré.