External Secrets Operator

À quoi il sert

External Secrets Operator (ESO) fait arriver des secrets dans un cluster Kubernetes sans qu'ils passent par Git. La valeur vit dans un gestionnaire de secrets (Scaleway Secret Manager, Vault, OpenBao, AWS Secrets Manager...) ; Git ne contient qu'une référence, la ressource ExternalSecret. Un SecretStore ou un ClusterSecretStore décrit comment joindre le gestionnaire, et l'opérateur crée puis rafraîchit périodiquement le Secret Kubernetes correspondant.

Quand le choisir

Avec le GitOps, dès qu'un gestionnaire de secrets est disponible ou qu'il y a plusieurs clusters : les valeurs, leur historique et leurs droits sont centralisés, et la rotation d'un secret est séparée des livraisons. C'est l'approche que recommande la documentation d'Argo CD (résolution dans le cluster de destination), et celle de Lyneko, avec Scaleway Secret Manager, pour les secrets des applications comme pour ceux d'Argo CD.

Points d'attention

• Le fournisseur Scaleway est classé alpha dans la page de stabilité du projet : lisez les notes de version avant chaque mise à jour.
• Pouvoir créer un ExternalSecret, c'est pouvoir lire n'importe quel secret du magasin : restreignez les namespaces autorisés par les conditions du ClusterSecretStore, et séparez les magasins par niveau de sensibilité.
• L'identifiant d'accès au gestionnaire ne peut pas venir d'ESO : il est créé à l'installation du cluster (à la main ou par Terraform), en lecture seule et limité à un projet.
• Chez Scaleway, un secret créé sans projet explicite atterrit dans le projet par défaut de la clé d'API utilisée, que le magasin ne voit pas forcément.
• Un pod qui lit un secret par variable d'environnement ne voit la nouvelle valeur qu'après redémarrage.

Par où commencer

La leçon Les secrets du cours GitOps avec Argo CD, qui retire de Git un mot de passe de base de données au profit de Scaleway Secret Manager, et compare ESO à Sealed Secrets.