Secrets

Let's think about it this way for a second

The concept behind a Secret is similar to a ConfigMap — you can inject key-value data into a Pod as environment variables or files. The difference is that Secret data is base64-encoded, and Kubernetes lets you lock it down more tightly with access control (RBAC) — but base64 is NOT 'encryption'; decoding it gets you straight back to the original value! If you want Secrets to be truly secure in production, you need to enable etcd encryption at rest (or use an external secret manager like Vault or AWS Secrets Manager).

Let's connect this to a real scenario

You can create a database password as a Secret and wire it into a Pod as an environment variable. Don't commit that Secret YAML file into a git repository — base64 encoding doesn't mean it's 'safe.' It can be decoded instantly, so if someone digs through git history, it'll be right there for the taking.

Secret = the sensitive-data version of a ConfigMap (passwords, API keys, certs)
It's base64-encoded — that's not encryption, and it's trivial to decode
For true production security, you need etcd encryption or an external secret manager

Let's look at it together

bash

# Create a Secret from literal values (kubectl base64-encodes it for you)
kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD=super-secret-value

# See it exists (value is hidden by default)
kubectl get secret db-secret

# Decode it yourself (proves base64 is not real encryption)
kubectl get secret db-secret -o jsonpath='{.data.DB_PASSWORD}' | base64 --decode

You should see

$ kubectl get secret db-secret
NAME         TYPE     DATA   AGE
db-secret    Opaque   1      5s

5-Minute Try-It

Create a Secret, decode it with `base64 --decode`, and prove to yourself firsthand that base64 is not encryption.

A Quick Word of Caution

Be careful that Secrets don't accidentally leak into logs, error messages, or third-party tools — make sure your application code never console.log's or prints a Secret value.