Vault, External Secrets & CSI: The Ultimate Guide to Secret Management in K8s

“Base64 is not encryption.” This phrase should be displayed prominently in every platform engineering team. Default Kubernetes Secrets are merely encoded, not encrypted. Anyone with access to the API or the etcd backend can read passwords, API keys, and certificates in plain text.

By 2026, professional Secret Management is a fundamental requirement to meet Compliance mandates and minimize the risk of data theft through “Lateral Movement” within the cluster. We explore how to securely manage sensitive data without disrupting your developers’ workflow.

The Problem: Secrets in Git (GitOps Dilemma)

If you’re using GitOps (e.g., with ArgoCD), you face a problem: you want to store the entire cluster state in Git, but passwords should never end up there.

There are three proven solutions to this problem:

1. External Secrets Operator (ESO): The Bridge to the Cloud

The External Secrets Operator is currently the most popular solution among medium-sized businesses. It acts as a synchronization layer.

• How it works: The actual secrets reside in an external vault (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or HashiCorp Vault).
• The advantage: Developers only create a reference (ExternalSecret) in Git. The operator securely retrieves the value from the vault and creates a local K8s Secret.
• Use case: Ideal if you are already heavily invested in a cloud provider.

2. HashiCorp Vault: The Gold Standard

Vault is the most powerful solution on the market. It is platform-independent and offers features that go far beyond simple storage.

• Dynamic Secrets: Vault can generate passwords “on the fly” that automatically expire after a short time. This way, an application never has a static database password.
• Injection via Sidecar: Through an agent injector, secrets are directly injected into the pod’s file system (shared memory) without ever appearing as a Kubernetes Secret object.
• Use case: Complex environments with high security requirements (financial sector, critical infrastructure).

3. Secrets Store CSI Driver: Direct Mount

This approach uses the Container Storage Interface to mount secrets like a drive.

• How it works: The secret does not exist in the Kubernetes database. It is mounted directly from the provider (e.g., Azure Key Vault) into a volume at pod startup.
• The advantage: Since no K8s Secret object is created, the data cannot be accidentally exposed via kubectl get secrets.

Comparison of Strategies

Why Secret Management Determines Your Security

Modern secret management offers two crucial advantages for medium-sized businesses:

1. Centralization: If an employee leaves the company or an API key is compromised, you only need to rotate the key in one place (in the vault). All affected apps in the cluster automatically receive the new value.
2. Audit Log: You can see exactly which pod and which service accessed which secret and when. This is invaluable for forensic investigations.

Conclusion: Get Rid of Plaintext Secrets

Implementing tools like the External Secrets Operator or HashiCorp Vault is a one-time effort that elevates your platform’s security to a new level. Anyone still manually encoding passwords in YAML files by 2026 is acting grossly negligent. The tools are mature—use them.

Technical FAQ: Secret Management

Should we use Bitnami Sealed Secrets? Sealed Secrets are a good starting point as they allow encrypted secrets in Git. However, they do not offer centralized management or integration with modern cloud vaults. By 2026, we recommend transitioning to the External Secrets Operator.

What happens if the vault or cloud vault is unreachable? With ESO, the local K8s Secrets remain, allowing apps to continue running. With the CSI driver or Vault injection, the startup of new pods fails. High availability (HA) of the secret store is therefore essential.

How secure is the connection between K8s and the vault? This is secured via service accounts and IAM roles (IRSA on AWS, Workload Identity on Azure/GCP). Thus, no “master passwords” need to be manually stored in the cluster.