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:
# Decoding a base64 secret from a CLI echo "YWRtaW5fc2VjcmV0X3Bhc3M=" | base64 --decode
Output: admin_secret_pass
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.
Secret YAML Manifest Example
apiVersion: v1
kind: Secret
metadata:
name: database-credentials
type: Opaque # Generic user-defined data
data:
# Values MUST be base64 encoded strings
DB_USERNAME: ZGJfYWRtaW4=
DB_PASSWORD: YWRtaW5fc2VjcmV0X3Bhc3M=