Secrets: handling passwords

Like config, but sensitive.

Sensitive settings — database passwords, API keys, TLS certificates — need the same "outside the image" treatment as regular config, but with more care. Secrets are Kubernetes’ object for holding this sensitive data, and they work much like ConfigMaps with one crucial difference in intent and handling.

Like config, but sensitive

A Secret holds key-value data just like a ConfigMap and is injected the same ways — as environment variables or as files mounted into the pod. You use it for anything sensitive: a database password, a third-party API key, a certificate. Your app reads it exactly as it would a config value, so from the application’s point of view nothing special is needed. The reason to use a Secret rather than a ConfigMap for these is that Secrets are the object type Kubernetes treats as sensitive — it avoids printing their values in most output, can restrict which nodes receive them, and the cluster’s security controls (access rules, encryption) are built around protecting Secrets specifically. So the rule is simple: non-sensitive settings go in ConfigMaps, sensitive ones go in Secrets, and both keep the values out of your image.

apiVersion: v1
kind: Secret
type: Opaque
data:
  DB_PASSWORD: c3VwZXJzZWNyZXQ=      # base64-encoded (see the warning below)
---
spec:
  containers:
    - name: web
      image: my-app:1.4
      env:
        - name: DB_PASSWORD
          valueFrom: { secretKeyRef: { name: db-secret, key: DB_PASSWORD } }
# Create from the command line without hand-encoding:
#   kubectl create secret generic db-secret --from-literal=DB_PASSWORD=supersecret

The one thing beginners must understand

Here is the important caveat: by default, the values in a Secret are only base64-encoded, which is not encryption — base64 is trivially reversible, so anyone who can read the Secret can decode the value in one command. A Secret is the right place for sensitive data, but "it is a Secret" does not by itself make it safe. Real protection comes from the controls around it, which you will learn properly later: restricting who is allowed to read Secrets (so not everyone can), and turning on encryption of the cluster’s data store so the values are genuinely encrypted at rest. For now, the beginner takeaways are three: put sensitive values in Secrets (not ConfigMaps or the image), do not commit Secret files with real values into public places, and understand that base64 is encoding for convenience, not a security boundary. Handled with those in mind, Secrets are how your app gets the passwords and keys it needs at runtime without ever baking them into the container image — which is exactly what you want.