Kubernetes Configuration & Secrets
Secrets — Storing Sensitive Data Safely
Base64 encodings, encryption at rest, and secret parameters mountings.
Interview: This is a common security question. Know that K8s Secrets are only Base64 encoded by default (NOT encrypted). Explain how to secure them: enable encryption at rest in etcd, restrict access using RBAC, mount them as memory-backed tmpfs volumes, and use external vault sync drivers.
What is a Secret?
A **Secret** is a Kubernetes object designed to store sensitive keys, passwords, certificates, and API tokens. Storing credentials in Secrets prevents private data from leaking in process tables, container logs, or Docker registries.
Base64 Encoding vs Encryption
*Crucial Security Concept:* Kubernetes Secrets are **Base64 encoded** by default. Base64 is a data formatting standard, not an encryption method. Anyone with read access to the cluster etcd backing store can decode these strings:
Securing Secrets in Production
To secure secrets in production, configure these security layers:
- Encryption at Rest: Configure the API Server to use an EncryptionConfiguration resource (linked to KMS providers like AWS KMS or HashiCorp Vault) to encrypt secret resources before writing them to etcd.
- RBAC Restrictions: Define Role-Based Access Control rules to restrict which service accounts and users can read or edit Secrets in the namespace.
- tmpfs Mounts: When mounted as volumes, the kubelet uses local memory-backed
tmpfsfilesystems. Secrets never touch physical worker node disks.