Kubernetes
Kubernetes Secrets Management: From Basics to Production Security
Kubernetes Secrets store sensitive data like API keys, database passwords, and TLS certificates. By default, Secrets are stored as base64-encoded values in etcd with no encryption, which is not sufficient for production. This guide covers how to secure secrets properly using encryption, external managers, and least-privilege access.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Default Secrets and Their Limitations
A Kubernetes Secret is a resource with `kind: Secret` that holds key-value pairs in base64 encoding. You can mount it as environment variables or files in a pod. The problem: base64 is not encryption. Anyone with read access to Secrets in a namespace can decode them. Additionally, Secrets stored in Git repositories (even in manifests) are visible to anyone with repo access. Never commit raw Secret manifests to version control. Use `kubectl create secret generic` to create them imperatively, or use a secrets management tool.
Encryption at Rest with KMS
Enable etcd encryption at rest by configuring the API server with an EncryptionConfiguration that specifies a KMS provider (AWS KMS, GCP KMS, or Azure Key Vault). This ensures Secrets are encrypted before being written to etcd. Managed Kubernetes services handle this configuration for you: EKS supports envelope encryption with a customer-managed KMS key, GKE encrypts etcd by default with Google-managed keys, and AKS supports customer-managed keys via Azure Key Vault. This protects against etcd data exposure from backups or disk theft.
External Secrets Operator and Vault Integration
The External Secrets Operator (ESO) syncs secrets from external providers (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault) into native Kubernetes Secrets. You define an ExternalSecret resource that references a remote secret by path, and ESO creates and refreshes the Kubernetes Secret automatically. This is the recommended approach for production: secrets are managed centrally, access is audited, rotation is handled by the external provider, and developers never touch raw secret values. Vault additionally offers dynamic secrets that generate time-limited credentials on demand.
Sealed Secrets for GitOps Workflows
Bitnami Sealed Secrets let you encrypt Secret manifests so they can be safely committed to Git. Install the SealedSecret controller in your cluster and use the `kubeseal` CLI to encrypt a Secret manifest with the controller's public key. The resulting SealedSecret resource is safe to store in Git; only the in-cluster controller can decrypt it. This fits GitOps workflows where all resources are defined in Git: ArgoCD or Flux apply the SealedSecret, and the controller decrypts it into a regular Secret. Rotate the controller's key pair periodically.
Why Anubiz Engineering
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.