Skip to main content
Welcome to the HashiCorp Vault series! In this lesson, we’ll review how Kubernetes stores sensitive data in Secrets, highlight key drawbacks, and prepare for a secure injection of dynamic secrets using Vault.

Why Use Kubernetes Secrets?

Managing sensitive data—passwords, API tokens, SSH keys—is critical in any deployment. Kubernetes Secrets help you:
  • Decouple credentials from application pods and container images
  • Store sensitive values centrally in etcd (the Kubernetes key-value store)
  • Consume secrets as mounted volumes or environment variables
Kubernetes Secrets are only base64-encoded, not encrypted by default. Any user with API or etcd access can decode them.
Learn more in the Kubernetes Secrets documentation.

Creating a Generic Secret

Create a simple Secret in one command:
Inspect it as YAML:
Decode it easily:

Viewing Secrets Directly in etcd

With etcd client certificates, stored Secrets appear in plain text:

Mitigation: Encryption at Rest

Kubernetes supports encrypting Secrets in etcd with an EncryptionConfiguration.
  1. Create /etc/kubernetes/pki/encryption-config.yaml:
  2. Update the API server flags:
  3. Restart the kube-apiserver. All new Secrets will be encrypted in etcd.
To encrypt existing Secrets, run:
After re-encryption, etcd shows only metadata:

Best Practices for Kubernetes Secrets

Next Steps

In the next lesson, we’ll dive into the Vault Kubernetes Agent Injector—a mutating admission webhook that injects secrets via init and sidecar containers, removing static Kubernetes Secrets altogether.

Watch Video