Les Secrets Kubernetes sont-ils chiffrés par défaut ?

Le mot « Secret » et le blob base64 opaque d'un manifeste donnent un faux sentiment de sécurité. Cette question vérifie que vous savez ce que Kubernetes fait réellement par défaut.

Ce que dit la documentation

Les Secrets Kubernetes sont, par défaut, stockés sans chiffrement dans le magasin de données sous-jacent du serveur d'API, etcd. Toute personne ayant accès à l'API peut récupérer ou modifier un Secret, tout comme toute personne ayant accès à etcd. De plus, toute personne autorisée à créer un Pod dans un espace de noms peut s'en servir pour lire n'importe quel Secret de cet espace, y compris indirectement via un Deployment.

Le base64 n'est pas du chiffrement

Les valeurs du champ data d'un Secret sont encodées en base64 pour que des données binaires tiennent dans du YAML/JSON. N'importe qui peut les décoder en une commande ; cela n'apporte aucune confidentialité.

Que faire

La documentation liste au minimum : activer le chiffrement au repos des Secrets, configurer un RBAC au moindre privilège sur les Secrets, restreindre l'accès aux Secrets à des conteneurs précis et envisager des fournisseurs de magasins de secrets externes (par exemple via le Secrets Store CSI Driver).

Pourquoi les distracteurs échouent

• « Le base64 chiffre » confond encodage et chiffrement.
• « Clé par espace de noms » est inventé ; aucun défaut de ce type n'existe.
• « Les espaces de noms isolent totalement » — ils aident à cadrer le RBAC, mais l'accès dépend des permissions accordées, y compris la création de Pods.

Ce que veulent les recruteurs

« Pas par défaut — activer le chiffrement au repos, verrouiller le RBAC (y compris qui peut créer des Pods) et envisager un magasin externe. »