Skip to content

Secrets

Summary

Secrets management and identity infrastructure for Kubernetes and cloud environments: a central secrets platform (HashiCorp Vault, with the MPL-2.0 fork OpenBao as an alternative), a Kubernetes sync operator (External Secrets Operator), file-level encryption for Git (SOPS), and an open-source identity provider (Zitadel). The first three store or deliver secrets; Zitadel issues identities and tokens that other systems (including Vault) trust. It is an IdP, not a secrets store.

← Knowledge Base

How the Topics Relate

SOPS and ESO feed Kubernetes from Git and from external stores, Vault generates and stores the credentials, and Zitadel authenticates the people and apps that ask for them.

flowchart LR
    GIT["Git repository"] -->|"SOPS-encrypted files"| FLUX["Flux / Argo CD"]
    FLUX -->|"ExternalSecret manifests"| ESO["External Secrets Operator"]
    ESO -->|"Kubernetes auth, fetch"| VAULT["Vault / OpenBao"]
    ESO -->|"fetch"| CSM["Cloud secret managers<br/>(AWS SM, GCP SM, Azure Key Vault)"]
    ESO -->|"create / update"| SEC["Kubernetes Secret"]
    FLUX -->|"decrypted Secret"| SEC
    SEC --> POD["Application Pod"]
    ZIT["Zitadel (OIDC IdP)"] -->|"ID tokens for humans"| VAULT
    ZIT -->|"OIDC login"| POD

Topics

Topic What it is Latest version License
External Secrets Operator CNCF Sandbox Kubernetes operator that syncs secrets from about 40 external providers (Vault, OpenBao, AWS, GCP, Azure, and more) into native Secrets; PushSecret and generators for the reverse path and short-lived values 2.11.0 (2026-09-18) Apache-2.0
SOPS CNCF Sandbox CLI and Go library that encrypts values in YAML, JSON, ENV and INI files (and whole binary files) for Git, with age, PGP, AWS/GCP KMS, Azure Key Vault, Vault/OpenBao Transit or HuaweiCloud KMS master keys 3.13.3 (2026-07-23) MPL-2.0 (CNCF health review open)
Vault IBM/HashiCorp identity-based secrets platform: dynamic secrets, Transit encryption, PKI, central policy and audit; OpenBao 2.7.0 (MPL-2.0, OpenSSF) is the community fork 2.1.1 (2026-09-16) BSL 1.1 (Enterprise commercial)
Zitadel Identity and access management (not a secrets store): event-sourced IdP with certified OIDC, SAML 2.0, passkeys, SCIM 2.0 and multi-tenant organizations v4.19.1 (2026-09-23) AGPL-3.0 core (Apache-2.0 protos, MIT login and clients)

Comparisons

Comparison Scope
Secrets Management Comparison Vault vs ESO vs SOPS (plus OpenBao): layers, features, integration patterns, overhead, cost, multi-cluster, compliance
Identity Provider Comparison Zitadel vs Keycloak vs authentik vs Ory: licensing, architecture, multi-tenancy, protocols

All comparisons: Comparisons index.

When to Use Which

This condensed flow matches the decision guides in the comparison pages.

flowchart TD
    START{"What is the problem?"}
    START -->|"Authenticate users<br/>or apps (SSO, OIDC)"| IDP["Identity provider:<br/>Zitadel (or Keycloak, authentik, Ory)"]
    START -->|"Store or deliver secrets"| Q1{"Need dynamic credentials,<br/>PKI or Transit?"}
    Q1 -->|"Yes"| VAULT["Vault<br/>(OpenBao if OSI license required)"]
    Q1 -->|"No"| Q2{"Secrets already in an<br/>external store?"}
    Q2 -->|"Yes"| ESO["External Secrets Operator"]
    Q2 -->|"No"| SOPS["SOPS (encrypt in Git)"]
    VAULT -.->|"deliver to Kubernetes"| ESO
Need Start with Details
Secrets in Git for GitOps, no new infrastructure SOPS (age) SOPS + Flux
Existing cloud secret manager, Kubernetes consumers ESO Decision guide
Dynamic database or cloud credentials, PKI, encryption as a service Vault, or OpenBao for an OSI license Vault vs OpenBao
Secrets must never land in etcd Secrets Store CSI Driver or Vault Agent injection ESO fit
SSO and multi-tenant B2B login Zitadel Identity Provider Comparison

Landscape

Secrets management moved from static credential storage to dynamic, identity-based access driven by zero-trust principles. The central problem, "secrets sprawl", is credentials scattered across environment variables, CI/CD configuration, Kubernetes Secrets (base64-encoded, not encrypted unless etcd encryption at rest is enabled), Helm values and laptops, which makes rotation and audit hard.

GitOps sharpened the problem by putting configuration in Git, which calls for either encrypting secrets in the repository (SOPS, Sealed Secrets) or referencing an external store (External Secrets Operator, Vault Secrets Operator). Vault remains the most feature-rich central store, but its BSL 1.1 license (since 1.15) and IBM ownership (since 2025-02-27) led to the MPL-2.0 OpenBao fork, and its operational cost keeps cloud-native managers (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) attractive for single-cloud teams.

The Secrets Store CSI Driver mounts secrets from external stores as tmpfs volumes without creating Kubernetes Secret objects, which keeps values out of etcd. Rotation remains an operational challenge, particularly for database credentials and TLS certificates that need coordinated restarts or connection pool refreshes.

Identity-first security

Workloads increasingly authenticate to secret stores with short-lived tokens instead of static credentials: OIDC federation (AWS IRSA, GCP Workload Identity, Azure Workload Identity), SPIFFE identities (Vault 2.0 adds SPIFFE JWT-SVIDs), or Kubernetes ServiceAccount tokens. Human access follows the same pattern through an IdP such as Zitadel feeding Vault's OIDC auth method.

Key Concepts

Dynamic Secrets

Secrets generated on demand with automatic expiration, which limits the damage of a leak. Vault's database secrets engine, for example, creates a unique database user for each requester with a TTL (for example, 1 hour) and revokes it when the lease expires. Every issuance and revocation is audited. Engines exist for databases (PostgreSQL, MySQL, MongoDB), cloud providers (AWS, GCP, Azure), PKI, SSH, and Kubernetes. ESO can request such credentials through its VaultDynamicSecret generator. Details: Vault leases.

Envelope Encryption

How it works

Data is encrypted with a data encryption key (DEK), and the DEK is encrypted with a key encryption key (KEK) held in a KMS or by a key holder. SOPS uses one AES-256-GCM data key per file to encrypt every value, then stores a copy of that data key wrapped by each master key (age, PGP, AWS KMS, GCP KMS, Azure Key Vault, Vault/OpenBao Transit, HuaweiCloud KMS). The file is safe in Git; decrypting needs access to at least one master key. Vault's Transit engine offers envelope encryption as a service. Details: SOPS envelope encryption model.

External Secrets Sync

Synchronizing secrets from an external provider into Kubernetes Secret objects, so workloads that expect files or environment variables need no SDK. ESO reconciles on a refreshInterval (default 1h) and supports Go templating to combine sources into one Secret. Its stable external-secrets.io/v1 API has two pairs of resources:

  • SecretStore / ClusterSecretStore: connection and authentication to the provider (a cluster store can be restricted with namespace conditions).
  • ExternalSecret / ClusterExternalSecret: which secrets to fetch, how to map keys, and how often to refresh.

Vault Secrets Operator does the same for Vault only. Details: ESO architecture.

OIDC Federation

Workloads authenticate with short-lived OIDC tokens issued by their platform instead of static credentials. Kubernetes issues projected ServiceAccount tokens that conform to OIDC, and cloud providers exchange them for temporary credentials:

  • AWS IRSA: maps ServiceAccounts to IAM roles through an OIDC provider registered in IAM.
  • GCP Workload Identity: binds ServiceAccounts to Google service accounts through a workload identity pool.
  • Azure Workload Identity: uses federated credentials on Entra ID applications to trust Kubernetes-issued tokens.

Vault supports Kubernetes and JWT/OIDC auth methods, so pods can authenticate without a pre-provisioned secret.

Identity-Based Access

Access to secrets is decided by the authenticated identity of the caller rather than network location. In Vault, policies bind to identities (Kubernetes ServiceAccounts, LDAP groups, OIDC claims), and each identity gets the minimum set of paths. Combined with dynamic secrets, credentials are both narrowly scoped and short-lived. The same principle appears in cloud IAM, Kubernetes RBAC, and database role grants; an IdP such as Zitadel is where human and application identities originate.

Sources

Open Questions

  • As cloud secret managers add rotation and cross-region replication, when does self-hosted Vault or OpenBao remain justified for a single-cloud organization?
  • Where is the right boundary between SOPS (encrypt in Git) and ESO (sync from a provider): should SOPS be limited to bootstrap secrets?
  • How does SPIFFE/SPIRE compare to Kubernetes-native OIDC federation for workload identity across clusters, and when does its extra complexity pay off?
  • What will the CNCF TOC decide for SOPS in health review cncf/toc#2098 (relicense, archive, or move)?
  • Should OpenBao get its own topic page as its feature set diverges from Vault Community Edition?