Why Kubernetes Native Secrets Fail at Scale
Kubernetes secrets are base64-encoded, not encrypted. The etcd encryption keys live on the same node, so cluster-admin access (or SSH access to the node) means full credential access. Rotation is manual and done at the cluster level. At scale, that combination breaks most security policies. These three gaps: no real encryption at rest, coarse access control, and manual rotation, are why Paul Stamp and Nick Png argue vanilla Kubernetes secrets are “not a practical option” for organizations with real security requirements.
Vault as a Certificate Authority for OpenShift
Cert-manager, deeply integrated with OpenShift, can replace the default ingress controller and API server certificates with ones rooted in Vault. For Istio-based service mesh, cert-manager intercepts the CSR flow: instead of Istio’s self-signed CA issuing the workload cert, the request travels up to Vault as root CA, and the resulting certificate lands in the Envoy proxy sidecar. This same chain covers OpenShift’s console, registry, and internal TLS. Vault holds the root; cert-manager distributes the leaves.
Three Ways to Get Secrets into Pods
Three methods move secrets from Vault into pods. The Secret Store CSI driver mounts credentials directly into a running pod as a volume, skipping etcd. The agent sidecar runs Vault agent inside the pod itself, so the secret never passes through cluster infrastructure. VSO and ESO both sync Vault secrets into Kubernetes secret objects. VSO fits teams already deep in HashiCorp tooling and gets automatic pod restarts on rotation. ESO is the on-ramp for OpenShift teams with secrets spread across multiple cloud providers.
Bypassing etcd and the Zero Trust Pattern
VSO 1.2.1 adds pod-direct secret injection, bypassing etcd the same way CSI does while keeping Vault’s lifecycle management. KubeKMS v2, new to OpenShift, moves the key-encryption key off the node and into Vault. Every etcd read generates a fresh data-encryption key, with no measurable performance impact. On top of those capabilities, Red Hat’s zero trust validated pattern ships Vault as its default secrets layer, built by product managers, architects, and field CTOs working together. A sandbox pattern is now available at validatedpatterns.io.
Notable Quotes
this is where Vault shines Paul Stamp · ▶ 3:51
basically it’s probably the most secure. Nick Png · ▶ 7:34
your credentials are gone right like Nick Png · ▶ 15:06
Key Takeaways
- Kubernetes secrets are base64-encoded, not encrypted, and etcd keys live on the node by default.
- VSO 1.2.1 injects secrets directly into pods, bypassing etcd entirely and removing a network bottleneck.
- Red Hat’s zero trust validated pattern ships with Vault as the default secrets layer, with a sandbox available now.