What is a Secret, and how does it differ from a ConfigMap?

Creating and consuming a Secret

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=          # base64("admin")
  password: c3VwZXJzZWNyZXQ=  # base64("supersecret")

spec:
  containers:
    - name: app
      envFrom:
        - secretRef:
            name: db-credentials

Consumption (env vars or mounted volumes) works identically to ConfigMaps — the key practical difference is in how Kubernetes handles the data, not in the mechanics of using it in a Pod spec.

The critical misconception: base64 is not encryption

echo "c3VwZXJzZWNyZXQ=" | base64 -d
# supersecret

Base64 is a reversible encoding, not encryption — anyone with read access to the Secret object (via kubectl get secret db-credentials -o yaml, or direct etcd access) can trivially decode it back to plaintext. Base64 exists purely so arbitrary binary data (like a TLS private key) can be represented safely inside YAML/JSON text, not to provide any confidentiality. A Secret's actual security comes entirely from who is authorized to read it (RBAC) and whether the underlying storage is encrypted — not from the encoding itself.

What Kubernetes does provide, beyond plain ConfigMaps

• Excluded from some default output — kubectl describe pod doesn't print a mounted Secret's actual values (though kubectl get secret -o yaml still shows them to anyone with permission to run that command).
• tmpfs (memory-backed) storage on nodes — a mounted Secret volume is typically backed by tmpfs (RAM), not written to the node's actual disk, reducing the risk of leftover sensitive data on a decommissioned or compromised node's filesystem.
• Encryption at rest, if explicitly configured — by default, Secrets are stored in etcd with no encryption beyond base64 (i.e., effectively plaintext to anyone with etcd access); enabling encryption at rest (a control-plane configuration, not automatic out of the box) actually encrypts Secret data before it's written to etcd.

What Secrets still don't solve on their own

Even with encryption at rest enabled, anyone with sufficient RBAC permission to read the Secret object through the API server gets the plaintext value back — Kubernetes-native Secrets don't provide fine-grained audit trails of secret access the way a dedicated secrets manager typically does, and rotating a Secret's value still requires updating the object and getting consuming Pods to pick up the change (see the ConfigMap question's note on env vars vs. mounted volumes applying equally here). For production systems with genuinely sensitive data, many teams layer an external secrets manager (HashiCorp Vault, AWS Secrets Manager, paired with a tool like External Secrets Operator that syncs values into native Kubernetes Secrets, or injects them directly at runtime) on top of, or instead of, relying purely on native Kubernetes Secrets.

Treat a Kubernetes Secret as "slightly better protected than a ConfigMap, but not encrypted by default and not a substitute for tight RBAC" — always enable encryption at rest for any cluster handling real sensitive data, restrict who can read Secret objects via RBAC as tightly as possible (see the security topic's least-privilege question), and consider an external secrets manager for the most sensitive values, audit requirements, or rotation needs.