← Back to Blog Tutorials

Quantum Safe Docker and Kubernetes Secrets: Post Quantum Cryptography for Container Workloads

8 min read

The Secret Management Problem

Kubernetes Secrets are base64-encoded in etcd. By default, etcd stores them in plaintext (base64 is encoding, not encryption). Most production clusters use Kubernetes Encryption at Rest to wrap Secrets with AES-256. The key-wrapping step, which uses the Kubernetes KMS provider, is where classical cryptography enters the picture.

Current Kubernetes Encryption Chain

  1. Kubernetes Secret resource stores arbitrary bytes (TLS certs, DB passwords, API keys).
  2. etcd encryption-at-rest wraps the Secret with an AES-256 DEK.
  3. The DEK is wrapped with a KEK from an external KMS provider (AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault).
  4. The KMS provider uses classical cryptography for most key-wrapping operations as of April 2026.

Where HNDL Applies

If an attacker compromises etcd backup archives plus the cloud KMS wrapped-key blob, they have all the encrypted material. A future CRQC unwraps the KEK, then the DEK, then reads your Secrets.

The Path to Quantum-Safe Kubernetes Secrets

  1. KMS provider with PQC: deploy your KMS with ML-KEM-hybrid wrapping. AWS KMS and Azure Key Vault are progressively deploying this through 2024-2026.
  2. Sealed Secrets with PQC: Bitnami Sealed Secrets encrypts Secrets client-side; future versions will use ML-KEM.
  3. External Secrets Operator with PQC backend: plug into HashiCorp Vault (future PQC support), AWS Secrets Manager (ML-KEM hybrid TLS), etc.
  4. SPIFFE/SPIRE for workload identity: classical ECDSA/Ed25519 today; PQC migration tracking.

Docker Secrets

Docker Swarm Secrets are stored encrypted at the Raft log. The encryption key is derived from the cluster secret. Classical cryptography today. Migration to PQC will follow the same pattern as Kubernetes.

Practical Near-Term Steps

  1. Ensure Kubernetes etcd encryption-at-rest is enabled (many clusters forget this).
  2. Use a KMS provider that is migrating to PQC (AWS KMS, Azure Key Vault).
  3. For ultra-sensitive Secrets, encrypt client-side with QNSQY or equivalent before putting into Kubernetes Secret.
  4. Track CNCF and Kubernetes SIG-Auth for PQC roadmap items.

Frequently Asked Questions

Is Kubernetes etcd encrypted by default?

Only if you explicitly configure encryption-at-rest via kube-apiserver flags. Many production clusters have this enabled, but not all.

Should I use Sealed Secrets?

Sealed Secrets is good for GitOps workflows (encrypting Secrets into git). PQC variants are expected through 2026-2027.

Is HashiCorp Vault quantum-safe?

Vault supports various KMS backends. Vault's direct cryptography is classical as of April 2026. PQC support is on the roadmap but not generally available.

How urgent is migrating Kubernetes Secrets?

Depends on Secret confidentiality lifetime. Database passwords can be rotated; certificates with long validity (especially embedded in devices) need early migration.

Sources

  1. Kubernetes Encrypting Secret Data at Rest
  2. AWS KMS PQC

Related Articles

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY

Originally published at quantumsequrity.com/blog/docker-kubernetes-quantum-safe-secrets.