We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Kubernetes & Containers
A K8s resource for storing sensitive data like passwords, tokens, and certificates. Base64-encoded by default; use encryption at rest and RBAC to properly secure them.
In short
A Kubernetes Secret is a built-in API object that stores small pieces of sensitive data, like database passwords, API tokens, TLS certificates, and SSH keys, so that pods can read them at runtime without baking the values into container images or plain manifests. By default the data is only base64-encoded, not encrypted, so production clusters add encryption at rest and RBAC to actually keep it private.
In short
A Kubernetes Secret is a built-in API object that stores small pieces of sensitive data, like database passwords, API tokens, TLS certificates, and SSH keys, so that pods can read them at runtime without baking the values into container images or plain manifests. By default the data is only base64-encoded, not encrypted, so production clusters add encryption at rest and RBAC to actually keep it private.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Kubernetes Secret across a run of lessons, not one page. These 4 alone are about 68 minutes of step-by-step reading, every one with a quiz.
Storing, accessing, and rotating sensitive credentials. API keys, database passwords, tokens, and certificates.
Protecting stored data from unauthorized access, even if an attacker gets physical access to the disk.
Securing containers from image to runtime, scanning, hardening, least privilege, and runtime protection.
The simplest way to identify and authenticate API consumers, a shared secret with limits.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Secrets Managementpay once,
yours for life
A Secret is a namespaced object in the Kubernetes API, the same way a Pod or a ConfigMap is. It holds a map of key-value pairs under a data field, where each value is a base64 string. The point is to separate sensitive configuration from your code and your pod specs, so a database password lives in one managed place instead of being copy-pasted into ten Deployment files.
There are typed Secrets for common cases. Opaque is the generic catch-all. kubernetes.io/tls holds a cert and private key for ingress. kubernetes.io/dockerconfigjson holds registry credentials so the kubelet can pull private images. kubernetes.io/service-account-token used to mint tokens for in-cluster API access, though modern clusters issue short-lived projected tokens instead.
A single Secret is capped at 1 MiB. That limit is deliberate. Secrets are not a file store. They are for small credentials, and packing large blobs in them puts pressure on etcd, where every Secret in the cluster is stored.
A pod consumes a Secret in one of two ways. You can mount it as a volume, where each key becomes a file under a directory like /etc/secrets, which the kubelet keeps in a tmpfs RAM-backed filesystem so the value never touches the node disk. Or you can inject keys as environment variables with valueFrom.secretKeyRef. Volume mounts are generally preferred because mounted Secrets update when the source Secret changes, while environment variables are frozen at pod start, and env values are easier to leak through logs or a crashed process dump.
The base64 encoding trips up almost everyone. It is encoding, not encryption. Anyone who can run kubectl get secret mysecret -o yaml and pipe the value through base64 -d sees the plaintext instantly. The real protection comes from three layers around the Secret, not from the encoding itself.
First, RBAC, so only the service accounts and humans that need a Secret can get or list it. Second, encryption at rest, configured with an EncryptionConfiguration so the API server encrypts Secret data before writing it to etcd, ideally backed by a KMS provider like AWS KMS or Google Cloud KMS rather than a static local key. Third, locking down etcd access and node access, since a Secret mounted into a pod is readable by anyone who can exec into that pod or reach the node.
Use a Secret for any value you would not want printed in a build log or checked into git: passwords, tokens, TLS material, signing keys. Use a ConfigMap, which is the unencrypted sibling, for non-sensitive config like feature flags and log levels. The two have nearly identical APIs, so the choice is purely about sensitivity.
The main trade-off is that native Secrets store the actual value in etcd inside your cluster, and that value still has to come from somewhere. If you commit raw Secret YAML to git, you have just leaked the credential. Teams solve this with Sealed Secrets, which encrypt the value so it is safe to commit and only the in-cluster controller can decrypt it, or with the External Secrets Operator, which leaves the real value in a dedicated manager and syncs it into a Kubernetes Secret on demand.
For higher-security setups, many teams skip the etcd copy entirely. The Secrets Store CSI Driver mounts values straight from HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault into the pod at runtime, so the source of truth is an external vault with audit logging and rotation, and Kubernetes is just the delivery mechanism.
Say you run a payments API that needs a Postgres password. You create the Secret once with kubectl create secret generic db-creds --from-literal=password=s3cr3t. Kubernetes stores it as base64 in etcd, and with KMS encryption configured, the bytes in etcd are ciphertext.
In the Deployment, the container references it as a volume mount at /etc/db/password or as an env var DB_PASSWORD via secretKeyRef. The app reads it at startup and connects to Postgres. When you rotate the password, you update the Secret, and the mounted file in each pod changes within about a minute without a redeploy. An app that reads the file only at startup still needs to re-read it or restart to use the new value, and an env var never changes until the pod restarts.
Crucially the password never appears in the container image, the Deployment manifest in git, or the CI pipeline. RBAC limits get secret db-creds to the payments service account and the on-call team, and an audit log records every read. That layered setup, not the base64 string, is what makes the Secret safe.
Kubernetes / kubelet
The kubelet mounts Secrets into pods as tmpfs RAM-backed files and uses dockerconfigjson Secrets to pull images from private registries.
HashiCorp Vault
Integrated through the Secrets Store CSI Driver or the External Secrets Operator so the real credential stays in Vault and is synced or mounted into the cluster on demand.
AWS Secrets Manager and AWS KMS
KMS encrypts Secret data at rest in etcd via the EncryptionConfiguration, and Secrets Manager acts as the external source synced into Kubernetes Secrets.
Bitnami Sealed Secrets
Encrypts Secret values into SealedSecret objects that are safe to commit to git, with an in-cluster controller decrypting them into real Secrets.
No. By default the values are only base64-encoded inside etcd, which is trivial to decode. You must enable encryption at rest with an EncryptionConfiguration, ideally backed by a KMS provider, to get real encryption.
They have almost the same API and both inject data into pods as files or env vars. The difference is intent and handling: Secrets are for sensitive data and can be encrypted at rest and tightly controlled with RBAC, while ConfigMaps are for plain non-sensitive configuration.
Prefer a volume mount. Mounted Secrets update automatically when the Secret changes and are less likely to leak, while environment variables are fixed at pod start and can show up in logs, crash dumps, or child processes.
Not raw Secrets, since base64 is not encryption and you would be publishing the credential. Use Sealed Secrets to commit an encrypted form, or the External Secrets Operator to keep the real value in an external manager like Vault.
Up to 1 MiB per Secret. Secrets live in etcd and are meant for small credentials, not for storing large files or blobs.
Kubernetes ConfigMap
A K8s resource that stores non-sensitive configuration data as key-value pairs. Pods read ConfigMaps as environment variables or mounted files, decoupling config from code.
Secret Management
Securely storing and distributing credentials, API keys, and certificates. Tools like Vault, AWS Secrets Manager, and SOPS prevent secrets from leaking into code or logs.
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Container
A lightweight, isolated environment that packages an application with its dependencies. Shares the host OS kernel, unlike VMs. Starts in milliseconds.
Kubernetes Pod
The smallest deployable unit in Kubernetes: one or more containers sharing network and storage. Pods are ephemeral; if one dies, K8s creates a replacement.
This page explains the idea. The "Secrets Management" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Secrets Management lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Kubernetes Secret in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
