A teammate claims Secret objects are encrypted because data values appear as base64 in YAML. What correction is accurate?
Select an answer to reveal the explanation.
Short Explanation
Base64 is bubble wrap, not a vault: anyone who can see it can unwrap it in one command. Those Secret values are just encoded, and by default they sit unencrypted in etcd. If you want real protection you've got to turn on encryption at rest and lock down RBAC yourself.
Full Explanation
Base64 is a reversible encoding that lets arbitrary bytes, such as keys and certificates, travel safely inside YAML and JSON manifests; it provides no confidentiality because anyone can decode it without a key. The Kubernetes documentation states that Secrets are, by default, stored unencrypted in the API server's underlying data store, etcd, and that anyone with API access or etcd access can read or modify them. Real protection therefore comes from separate controls: an EncryptionConfiguration on the API server that enables encryption at rest for Secrets, least-privilege RBAC on get, list and watch, and optionally an external secret store. Calling base64 an AES-256 scheme unique to Kubernetes fails because base64 is a standard encoding with no key, and encryption at rest requires explicit provider configuration. Claiming every Secret in etcd is automatically encrypted with a per-namespace passphrase derived from base64 fails because no such default mechanism exists; without an encryption provider the data is stored in plain form. Saying base64 stops anyone with get permission from reading the Secret fails because get returns the encoded value, which decodes instantly. Exam caveat: expect CKAD items to test that base64 is not encryption and that encryption at rest is opt-in. Operational check: run kubectl get secret with -o jsonpath on a key, pipe it to base64 -d, and review the API server flags for --encryption-provider-config.