Are Kubernetes Secrets encrypted by default?

The word "Secret" and the opaque base64 blob in a manifest give a false sense of safety. This question checks that you know what Kubernetes actually does by default.

What the documentation says

Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store, etcd. Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. In addition, anyone authorized to create a Pod in a namespace can use that access to read any Secret in the namespace, including indirectly through a Deployment.

Base64 is not encryption

Values you see in a Secret's data field are base64-encoded so that binary data fits in YAML/JSON. Anyone can reverse that with one command; it provides no confidentiality.

What to do

The docs list at minimum these steps: enable encryption at rest for Secrets, configure RBAC with least-privilege access to Secrets, restrict Secret access to specific containers, and consider external Secret store providers (for example via the Secrets Store CSI Driver).

Why the distractors fail

• "Base64 encrypts" confuses encoding with encryption.
• "Per-namespace key" is invented; no such default exists.
• "Namespaces isolate completely" — namespaces help scope RBAC, but access is decided by the permissions granted, including Pod creation.

What interviewers want

"Not by default — enable encryption at rest, lock down RBAC (including who can create Pods), and consider an external store."