Secrets

Mechanically, almost the same object

A Secret is consumed exactly like a ConfigMap — env var via secretKeyRef, envFrom, or a mounted volume. If you understood the last lesson, you already know how to use one. The only real differences are in what Kubernetes does with the data, and what you should assume about it.

base64 is not encryption

Open a Secret with kubectl get secret <name> -o yaml and the values are base64-encoded strings, not the plain text you wrote. It is extremely common to mistake this for security. It isn't: base64 is just an encoding — a reversible way to represent arbitrary bytes as plain text (the same trick email attachments have used for decades), not a cipher. Anyone who can read the Secret object through the API can decode it in one command: echo '<value>' | base64 -d. No password, no key, nothing to crack.

Linux aside: encodings like base64 translate data into a different representation with no secret involved — reversible by anyone, by design. Encryption transforms data using a key, reversible only by whoever holds that key. Confusing the two is one of the most common security misunderstandings in infrastructure work generally, not just Kubernetes.

What actually protects a Secret

Real protection comes from layers outside the Secret's own encoding:

• RBAC restricting who can get/list Secret objects at all — the thing actually worth getting right (Module 11).
• Encryption at rest for etcd itself, so a stolen disk doesn't hand over every Secret in the cluster — a cluster-operator-level setting, not something you configure per-Secret.
• In real production, often an external secret store (AWS Secrets Manager, Vault) with Kubernetes only holding a short-lived reference — exactly what Module 15 touches on for EKS.

None of that is "turn on a flag on the Secret" — it's about everything around the Secret.

The infrastructure analogy

Treat a Kubernetes Secret the way you'd treat a value sitting in a shared password vault with weak access controls: fine for convenience, not a substitute for actually restricting who's allowed to open the vault. The object type's name is aspirational, not a guarantee.

In the lab, you'll wire a Secret into a Pod and fix a realistic typo — a Secret key name that doesn't match what the Pod expects — the same failure mode as the ConfigMap lab, just one object type over.