Aller au contenu principal

External Secrets Operator

Overview

External Secrets Operator (ESO), c'est l'opérateur Kubernetes CNCF qui pense que tes secrets doivent rester dans des systèmes dédiés, pas en dur dans Git. Il synchronise automatiquement les secrets depuis Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager et 30+ autres providers vers tes secrets Kubernetes natifs. Si tu veux une gestion centralisée des secrets sans compromettre la sécurité, c'est parfait.

ESO fonctionne avec des CRDs (Custom Resource Definitions) simples : tu définis une SecretStore (où chercher), un ExternalSecret (quoi synchroniser), et l'opérateur crée automatiquement les secrets Kubernetes. Rotation automatique, templating avancé, multi-tenant avec namespaces isolation.

External Secrets Operator se distingue par son support multi-providers (30+ providers supportés), son statut CNCF (projet officiel), et sa philosophie GitOps-friendly (configuration déclarative, secrets pas dans Git).


Informations essentielles

PropriétéValeur
Site officielhttps://external-secrets.io/
Repositoryhttps://github.com/external-secrets/external-secrets
LicenceApache 2.0
OrganisationCNCF (Cloud Native Computing Foundation)
LangageGo
ProvidersHashiCorp Vault, AWS, Azure, GCP, GitLab, et 30+ autres

Fonctionnalités principales

Support multi-providers

  • HashiCorp Vault : KV, Database, Transit engines
  • Cloud providers : AWS Secrets Manager, Azure Key Vault, GCP Secret Manager
  • CI/CD : GitLab, Jenkins, GitHub
  • Databases : PostgreSQL, MySQL secrets
  • Autres : 1Password, Bitwarden, CyberArk, etc.

Synchronisation avancée

  • Sync one-time ou polling régulier
  • Rotation automatique des secrets
  • Template engines pour transformation des données
  • Conditions et filtres de synchronisation
  • Gestion des erreurs et retry logic

Sécurité et isolation

  • Multi-tenant avec namespace isolation
  • Service accounts dédiés par SecretStore
  • Chiffrement des données en transit
  • Audit logging complet
  • RBAC intégration native

CRDs intuitives

  • SecretStore/ClusterSecretStore : configuration du provider
  • ExternalSecret : définition de ce qui doit être synchronisé
  • SecretGenerator : génération de secrets dérivés
  • PushSecret : synchronisation inverse (K8s → externe)

Cas d'usage

  • Centralisation secrets : Vault/cloud comme source unique de vérité
  • GitOps security : Garder les secrets hors de Git
  • Multi-cloud : Même opérateur pour différents providers
  • Rotation automatique : Mise à jour automatique des secrets applicatifs
  • Dev/Staging/Prod : Différentes sources selon l'environnement

Installation

Via Helm

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets \
-n external-secrets-system \
--create-namespace

Via kubectl

kubectl apply -f https://raw.githubusercontent.com/external-secrets/external-secrets/main/deploy/crds/bundle.yaml
kubectl apply -f https://raw.githubusercontent.com/external-secrets/external-secrets/main/deploy/charts/external-secrets/templates/deployment.yaml

Vérification installation

kubectl get pods -n external-secrets-system
kubectl api-resources | grep externalsecrets

Utilisation basique

SecretStore pour Vault

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: vault-backend
namespace: example
spec:
provider:
vault:
server: "https://vault.example.com"
path: "secret"
version: "v2"
auth:
kubernetes:
mountPath: "kubernetes"
role: "external-secrets"

ExternalSecret synchronisation

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: app-secrets
namespace: example
spec:
refreshInterval: 30s
secretStoreRef:
name: vault-backend
kind: SecretStore
target:
name: app-secrets
creationPolicy: Owner
data:
- secretKey: password
remoteRef:
key: myapp/database
property: password
- secretKey: username
remoteRef:
key: myapp/database
property: username

AWS Secrets Manager

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: aws-secrets
spec:
provider:
aws:
service: SecretsManager
region: us-west-2
auth:
iam:
role: arn:aws:iam::123456789012:role/external-secrets-role

---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: rds-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets
kind: SecretStore
target:
name: rds-credentials
dataFrom:
- extract:
key: "prod/rds/credentials"

Template avancé

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: templated-secret
spec:
secretStoreRef:
name: vault-backend
kind: SecretStore
target:
name: myapp-config
template:
type: Opaque
data:
config.yaml: |
database:
host: {{ .host }}
port: {{ .port }}
username: {{ .username }}
password: {{ .password }}
data:
- secretKey: host
remoteRef:
key: myapp/db
property: host
- secretKey: port
remoteRef:
key: myapp/db
property: port

Avantages

  • CNCF project : projet officiel avec gouvernance et support long terme, c'est pérenne
  • Multi-providers : 30+ providers supportés, tu choisis ton système de secrets préféré
  • GitOps ready : configuration déclarative, secrets pas dans Git, c'est sécurisé
  • Templating puissant : transformation et composition des secrets, très flexible
  • Production ready : utilisé par de nombreuses entreprises, c'est prouvé

Limitations

  • Complexité initiale pour configurer les providers : mais la doc est excellente
  • Latence de synchronisation selon le refresh interval : configurable selon tes besoins
  • Dépendance réseau vers les systèmes externes : mais c'est le prix de la centralisation

Alternatives

  • Sealed Secrets : Secrets chiffrés stockés dans Git
  • SOPS : Chiffrement de fichiers avec clés multiples
  • Bank-Vaults : Opérateur spécifique Vault
  • Secrets Store CSI Driver : Mount secrets as volumes

Ressources