Secrets Management 101: Vault vs AWS Secrets Manager vs Kubernetes Secrets

"Just use a secrets manager" is easy advice that skips the actual question: which one, and why. Vault, AWS Secrets Manager, and native Kubernetes Secrets all get called "secrets management," but they solve different problems and have genuinely different security guarantees. Here's how to actually choose.

Kubernetes Secrets: convenient, and weaker than most people assume

Native Kubernetes Secrets are base64-encoded, not encrypted, by default. Base64 is an encoding, not encryption — anyone with get access to the Secret object (or etcd access) can trivially decode it. Encryption at rest for Secrets is an opt-in feature (EncryptionConfiguration) that a meaningful number of clusters simply never enable.

Use Kubernetes Secrets when: the secret's blast radius is genuinely limited, you've enabled encryption at rest, and RBAC on Secret objects is tightly scoped — not as your primary secrets management layer for anything sensitive.

Don't rely on them alone for: database credentials, API keys for external services, or anything an attacker with cluster read access shouldn't be able to trivially recover.

AWS Secrets Manager: strong for AWS-centric workloads, less useful outside it

Secrets Manager gives you real encryption (via KMS), fine-grained IAM-based access control, and automatic rotation for supported services (RDS, Redshift, DocumentDB) — rotation that Kubernetes Secrets and self-hosted Vault both require you to build yourself. The tradeoff is that it's an AWS-native service: using it well means your access control model is IAM, which is a strength if you're all-in on AWS and a real integration cost if you're multi-cloud or on-prem.

Use Secrets Manager when: you're primarily AWS-based and want rotation and access control that integrates natively with IAM without standing up separate infrastructure.

HashiCorp Vault: the most capable, and the most operational overhead

Vault is built specifically for secrets and does the most: dynamic secrets (short-lived database credentials generated on demand instead of static long-lived ones), encryption as a service, detailed audit logging, and cloud-agnostic design that works the same way whether you're on AWS, GCP, on-prem, or all three at once.

The cost is that Vault is another piece of infrastructure you now own — it needs to be deployed, unsealed, backed up, and kept highly available, because if Vault is down, everything that depends on it for secrets can't start. That operational burden is real and shouldn't be underestimated by a small team.

Use Vault when: you're multi-cloud, you want dynamic short-lived credentials rather than static long-lived ones, or your compliance requirements need the audit trail and access control granularity Vault provides — and you have the operational capacity to run it properly.

The pattern that actually works in Kubernetes

Most mature setups don't pick just one — they use an external secrets operator (like the External Secrets Operator or Vault's own CSI driver) to sync secrets from Vault or Secrets Manager into Kubernetes at runtime, so pods still consume secrets as native Kubernetes Secrets or mounted files, but the actual source of truth, encryption, and rotation live in a proper secrets manager — giving you Kubernetes-native ergonomics without Kubernetes-native weaknesses.

The one rule that matters regardless of which tool you pick

Whatever you choose, the failure mode to eliminate first is secrets in places that were never designed to hold them: environment variables visible via docker inspect or kubectl describe, values baked into container image layers, or plaintext in a CI/CD variable that logs get dumped into. Fixing that matters more than which secrets manager brand you pick.

Go deeper

We cover wiring a real secrets manager into a live Kubernetes deployment — dynamic credentials, rotation, the whole pipeline — hands-on in our DevSecOps Masterclass. If you haven't locked down the container layer yet, start with our Docker security checklist first — secrets management doesn't help much if the container itself is easy to break into.