External Secrets Operator
Keeps your passwords and API keys in a proper secrets vault (Vault, AWS Secrets Manager, etc.) instead of loose in Kubernetes config, while still letting your apps read them the normal Kubernetes way — free, open source, and CNCF-backed.
🔗 Visit External Secrets Operator
Description
Kubernetes has a built-in way to store secrets, but it's notoriously weak on its own — values are only base64-encoded, not encrypted, and there's no rotation. Teams that care about security keep their real secrets in a dedicated vault instead. The problem is bridging the two: your app expects a Kubernetes Secret, but your source of truth lives elsewhere. External Secrets Operator is that bridge — it watches your vault and automatically keeps a matching Kubernetes Secret in sync, like a courier that fetches the real document from the safe every time someone at the office needs a copy.
External Secrets Operator (ESO) is a Kubernetes operator that syncs secrets from over 40 external providers — HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault, and more — into native Kubernetes Secret objects, using declarative custom resources (ExternalSecret, SecretStore, ClusterSecretStore). It supports secret rotation, is a CNCF project with CII Best Practices certification and an OpenSSF Scorecard assessment, and has reached the v1beta1 API stability level with active multi-company maintenance. It's free and open source under Apache 2.0.
💬 Our review
The short version: if you're running Kubernetes and storing real secrets in a real vault (as you should), External Secrets Operator is close to the default, no-brainer way to get them into your pods — it's free, CNCF-governed, and supports basically every secret backend you'd realistically use.
The value here isn't flashy — it's plumbing, and good plumbing is exactly what you want for secrets. The provider list (40+) means you're unlikely to be locked out because your team picked an unusual vault, and the CNCF governance plus CII/OpenSSF certifications are meaningful signals for something that touches credentials: this isn't a side project, it's actively audited and maintained by multiple organizations.
The honest limits: it's an operator, so it adds another moving piece to your cluster that needs monitoring and RBAC of its own — misconfigure its permissions and you've built a very efficient secret-leaking pipeline instead of a secure one. It also doesn't replace the vault itself; you still need Vault, AWS Secrets Manager, or similar as the actual source of truth. Compared to Sealed Secrets (which encrypts secrets for safe Git storage but doesn't sync from an external vault) or raw native Kubernetes Secrets (no encryption, no rotation), ESO is the right choice specifically when you already have — or want — a centralized secrets manager and need Kubernetes to stay in sync with it.
💰 Pricing
📊 Global score
🤖 AI-enriched data
Open source (licence Apache 2.0), projet CNCF, gratuit sans palier payant.
Pros
Gratuit, open source, projet CNCF avec gouvernance active et certifications de sécurité (CII, OpenSSF Scorecard)
Supporte 40+ fournisseurs de secrets (Vault, AWS, GCP, Azure...)
Synchronisation déclarative et automatique, avec rotation des secrets
API stable (v1beta1), maintenu par plusieurs organisations
Cons
Ajoute un composant supplémentaire (operator) à surveiller et sécuriser dans le cluster
Ne remplace pas le vault lui-même — nécessite déjà un gestionnaire de secrets externe en place
Une mauvaise configuration RBAC de l'operator peut transformer un outil de sécurité en fuite de secrets