What is the difference between a ConfigMap and a Secret, and how secure are Secrets by default?
Quick Answer
Both inject configuration into pods, but Secrets are meant for sensitive data. By default a Secret is only base64-encoded (not encrypted) in etcd — you must enable encryption-at-rest and tight RBAC to actually protect it.
Detailed Answer
ConfigMaps hold non-sensitive key/value config (feature flags, URLs, tunables) that you mount as files or inject as env vars. Secrets are the same idea for sensitive values (passwords, tokens, TLS keys) with a few extra protections: they're stored separately, can be mounted as tmpfs (RAM) rather than disk, and are treated specially by tooling. The trap candidates miss: a Secret is base64-encoded, which is encoding not encryption — anyone who can read the Secret or etcd can trivially decode it. Real protection requires enabling encryption-at-rest for Secrets (EncryptionConfiguration, ideally backed by a KMS), locking down RBAC so few identities can read Secrets, and avoiding leaking them into logs or env. Many teams go further with an external secrets manager (Vault, AWS/GCP Secrets Manager) synced via the External Secrets Operator so the source of truth never lives in etcd.
Code Example
kubectl create secret generic db --from-literal=password='s3cr3t'
kubectl get secret db -o jsonpath='{.data.password}' | base64 -d # just decodes!
# Protect for real: EncryptionConfiguration (KMS) + RBAC restricting 'get secrets'Interview Tip
The line that scores: 'base64 is encoding, not encryption — Secrets aren't safe until you enable encryption-at-rest (KMS) and restrict RBAC.' Mention External Secrets Operator/Vault for bonus points.