Cybersecurity glossary
What is a Kubernetes Secret?
Learn what a Kubernetes Secret is, how etcd stores and mounts credentials, why base64 is not encryption, and which patterns reduce Secret sprawl and leakage.
Definition
A Kubernetes Secret is an API object that holds small pieces of sensitive data—tokens, passwords, certificates—so pods can consume them as files or environment variables instead of baking credentials into images or manifests in plaintext form.
Why Kubernetes Secrets matter
Applications need database passwords, webhook tokens, and TLS keys. If those strings live in container images or ConfigMaps, every clone and log line becomes a credential leak.
A Kubernetes Secret is the native object for that data. It is convenient and dangerous at the same time: every controller, backup, and RBAC grant that can get Secrets is a copy of production keys.
How a Secret reaches a process
A Secret object is created
CI, an operator, or a vault sync writes key/value data into the API. YAML in git is still a leak path.
etcd stores the object
Without encryption-at-rest, etcd and its snapshots hold decodeable values.
RBAC gates API reads
Users and service accounts with get/list/watch secrets can retrieve the payload via kubectl.
The pod spec references the Secret
envFrom, env valueFrom, or a volume mount selects keys for that container.
kubelet materializes the value
tmpfs files or environment variables appear in the container; the app reads them at start or reload.
Native Secret types and typical uses
Opaque
Generic key/value credentials: API tokens, passwords, arbitrary config.
TLS
Certificate and key pairs for Ingress and webhook servers.
dockerconfigjson
Registry pull credentials. A cluster-wide copy is a supply-chain prize.
Service account tokens
Projected, bound tokens for the Kubernetes API—not a place to store cloud access keys.
Kubernetes Secret versus a real vault
| Concern | Native Secret | Secrets manager / CSI |
|---|---|---|
| Encryption | Optional etcd encryption; YAML is not encrypted | Provider-managed encryption and often customer-managed keys |
| Audit of reads | API audit if enabled; kubelet mounts are harder to attribute | Per-identity retrieve events with cloud IAM |
| Rotation | Manual object update plus app reload | Dynamic or scheduled rotation with versioned values |
| Blast radius of etcd backup | Backup contains the secrets unless encrypted and tightly stored | Cluster backup need not contain the live credential |
| Cloud access keys | Static keys in etcd—avoid | Prefer workload identity; vault only if the API cannot federate |
Kubernetes Secret hygiene checklist
- Enable encryption at rest for Secret resources and protect etcd snapshots as production credentials.
- Never commit Secret YAML to git; use sealed-secrets, external-secrets, or a CSI driver from a vault.
- Restrict get/list/watch on secrets; do not grant it to namespace-wide debug Roles.
- Mount as files on tmpfs; avoid environment variables when the app can read a file.
- Disable automount of service account tokens on pods that do not call the Kubernetes API.
- Prefer workload identity over storing cloud access keys in Secret objects.
- Rotate the backing credential, not only the Kubernetes object, after any suspected leak.
- Scan CI logs, images, and helm values for Secret contents that escaped the object store.
The practical takeaway
A Kubernetes Secret is an API object for small sensitive values consumed by pods. Base64 is encoding, etcd is a database, and RBAC on secrets is a privileged permission.
Use native Secrets as a delivery slot, not as your only vault. Encrypt etcd, starve RBAC, prefer file mounts and workload identity, and rotate at the source when anything leaks.
Related security terms
Secrets Manager
External vaults that can inject into pods without storing long-lived values in etcd.
Secrets Management
The lifecycle discipline Kubernetes Secrets implement only partially.
Kubernetes RBAC
Who can get, list, or watch Secrets is as sensitive as the values themselves.
Workload Identity
Often a better substitute for storing cloud keys in Secret objects.
Secret Scanning
Catches Secret YAML and tokens that leaked into git, CI logs, or images.
Frequently asked questions
What is a Kubernetes Secret in simple terms?
It is a cluster object meant to hold credentials. Pods receive the values as files or env vars. It is more structured than putting passwords in a ConfigMap, but it is not a full vault.
Is base64 encoding encryption?
No. kubectl apply of a Secret typically stores base64 in the YAML you typed. Anyone with get secrets can decode it. Encryption at rest in etcd is a separate API server setting.
Where are Secrets stored?
In etcd (or an equivalent store) as API objects, unless you use an external secrets store CSI driver or a sync from a vault. etcd snapshots then contain those values.
Should I put Secrets in environment variables?
Prefer file mounts. Environment variables are easy to dump in crash logs, child processes, and /proc. Files can be tmpfs-backed and more tightly permissioned.
Can any pod in a namespace read all Secrets?
Not automatically, but a service account with list/get on secrets, or a volume reference in the pod spec, can. RBAC and admission must constrain both.
How do I rotate a Kubernetes Secret?
Write a new value, update consumers, then revoke the old credential at the source (IdP, database, cloud). Kubernetes will not rotate third-party passwords for you.
When should I avoid native Secrets?
When you need short-lived cloud credentials, centralized audit, or to keep plaintext out of etcd backups—use workload identity or a secrets manager CSI integration.
References
Explore authoritative guidance and frameworks related to kubernetes secret.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.