Are base64-encoded Kubernetes Secrets actually secure?

WHAT THIS TESTS The interviewer wants to know whether you grasp the difference between encoding and encryption, and whether you understand where Kubernetes Secrets are actually exposed. It is a security-literacy filter.

A GOOD ANSWER COVERS Base64 is a reversible encoding with no key, so it provides zero confidentiality; anyone can decode it instantly. The default behavior exists so that binary secret data can be embedded in YAML and JSON safely, and so values are not splattered as raw bytes across tooling. The threat it loosely addresses is casual over-the-shoulder viewing of a manifest, not a real attacker. Anyone with read access to etcd, with access to the node disk where etcd stores data, or with RBAC permission to get the Secret object can recover the plaintext. Genuine protection comes from enabling encryption at rest via an EncryptionConfiguration backed by a KMS provider, locking down RBAC so few subjects can read Secrets, restricting etcd network and disk access, and enabling audit logging.

COMMON WRONG ANSWERS Claiming Secrets are encrypted by default, or that base64 is a security measure. Saying that because data is in etcd it is automatically safe. Forgetting that mounted Secrets land in tmpfs readable by the Pod's processes.

LIKELY FOLLOW-UPS How do you enable encryption at rest? How does envelope encryption with a KMS plugin work? How would you rotate the data encryption key? Why might you prefer an external secret store over etcd entirely?

ONE CONCRETE EXAMPLE Run kubectl get secret db-creds -o jsonpath='{.data.password}' and pipe through base64 -d; the password appears in cleartext with no key required, proving the encoding is cosmetic. Contrast this with configuring an aescbc or kms provider in the API server's EncryptionConfiguration so the bytes in etcd are ciphertext.