A Kubernetes Secret is Base64-encoded, not encrypted. That single fact determines everything about how these manifests should be handled.
Base64 is not encryption
Anyone with get secrets in the namespace reads the plaintext with one command. So does anyone with access to etcd, unless encryption at rest is explicitly enabled — it is off by default in many distributions.
The practical consequences:
- A
Secretmanifest must never be committed to git. - Restrict
get secretsRBAC as tightly as you would restrict the secrets themselves. - Enable encryption at rest for etcd.
The commit-safe options
SealedSecret. Encrypted with the cluster controller's public key. Only that controller can decrypt it, so the manifest is safe in a public repository. This is the standard answer for GitOps.
kubeseal --format yaml < secret.yaml > sealed-secret.yamlExternalSecret. Holds no secret value at all — it is a pointer to AWS Secrets Manager, Vault or another backend, which the operator resolves at runtime. Best when you already run a secrets manager, and it gives you rotation without redeploying.
Both keep your git history free of credentials, which matters because git history is forever and is copied to every fork.
stringData or data
stringData takes plaintext and Kubernetes encodes it on write. data requires you to Base64-encode the values yourself.
Use stringData. It is readable, and it eliminates the double-encoding bug — encoding a value that Kubernetes then encodes again, producing a secret whose value is the Base64 of your secret.
Files beat environment variables
Environment variables leak more than people expect. They appear in kubectl describe pod for anyone with read access, in crash dumps, in /proc/<pid>/environ, and in any child process. Many error-reporting libraries capture the whole environment and ship it to a third party.
Mounting a secret as a file confines it to processes that read the file, and lets you update it without restarting the pod. Both options are shown in the consumption panel.
Never on the command line
# Wrong — lands in your shell history
kubectl create secret generic api --from-literal=KEY='sk_live_...'
# Better — from a file you delete afterwards
kubectl create secret generic api --from-file=KEY=./key.txtFrequently asked questions
Can I commit a Kubernetes Secret manifest?
No, unless it is a SealedSecret or an ExternalSecret. A plain Secret contains the credential in a trivially reversible encoding.
Is a Secret encrypted in etcd?
Only if encryption at rest is configured, which is not the default in many distributions. Check with your platform team before assuming it.
How do I rotate a secret without downtime?
Update the Secret, then restart the consuming pods — kubectl rollout restart deployment/x. Mounted files update automatically after a delay, but environment variables are fixed at process start, which is another argument for file mounts.
What about Docker Compose?
Compose secrets mount files into the container rather than setting environment variables, which is the better pattern for the same reasons. The manifest option here emits that structure.