Kubernetes simplifie le montage des secrets ; pas leur cycle de vie. Les équipes copient du base64 entre namespaces, forkent des charts Helm avec identifiants embarqués ou s’appuient sur des jetons longue durée faute de rotation fiable. Résultat : dispersion—personne ne sait quel secret soutient quelle charge, et la révocation devient une fouille archéologique.
Ancrez-vous sur une source externe unique—KMS cloud avec CSI, Vault, ou le gestionnaire du fournisseur—et traitez les Secrets du cluster comme des projections éphémères. L’accès par namespace via RBAC et identités IAM liées bat les kubeconfigs partagés cluster-admin.
Automatisez la rotation avec backoff et contrôles de santé. Préférez les identifiants à courte durée (OIDC workload identity, mots de passe base dynamiques) aux fichiers statiques. Pour les clés symétriques, documentez propriétaires, TTL et procédures de bris de glace.
Le GitOps complique la situation positivement : l’état désiré reste dans Git tandis que les références de secrets pointent vers des IDs externes. Jamais de clair dans Git ; sealed secrets ou opérateurs external-secrets avec périmètres serrés.
Préparez l’audit : inventaire indexé par charge, classification des données, tests de restauration trimestriels. Les exercices révèlent si vos sauvegardes de métadonnées secrètes valent les secrets eux-mêmes.
La plateforme doit publier des patrons dorés—un chart pour AWS Secrets Manager, un pour Vault Agent sidecar—et mesurer l’adoption plutôt que d’imposer du YAML sur mesure par service.
À lire aussi : conseil DevOps et modèles d’intervention.