Kubernetes Secrets: Managing Sensitive Data in Pods
A Kubernetes Secret is a dedicated object for storing sensitive data like API keys, separating them from your application code. It's used to inject database credentials or TLS certificates into pods.
Why it exists
Applications need credentials to function, but hardcoding passwords or API keys into container images is a major security vulnerability. Storing them in plain-text configuration is no better. Secrets were created to provide a dedicated, managed way to handle sensitive data within the Kubernetes ecosystem.
The mental model
Think of a Secret as a managed key-value store specifically for sensitive information. It's like a digital safe deposit box for your cluster. You define the sensitive data (like a database password) in the Secret object, and then grant specific Pods access to it, without ever exposing the data in your version-controlled application code or deployment files.
How it works
A Secret object stores data in key-value pairs. The values are stored in the Kubernetes control plane's database (etcd) as base64-encoded strings. This is encoding, not encryption, and is easily reversible. You can make a Secret's data available to a container in a Pod in three ways: as files in a volume mounted into the container's filesystem, as container environment variables, or by the kubelet when pulling images for the Pod.
When to use it
Use Secrets for any small piece of sensitive data your application needs. Common use cases include database credentials, API keys for external services, authentication tokens, and TLS certificates for securing network traffic with an Ingress.
When not to use it
Do not use Secrets for non-sensitive configuration; use a ConfigMap instead. Secrets are not designed for storing large files or binary data, as they are stored in memory on the API server and are limited in size (typically 1MB per Secret).
One canonical example
An application needs a password to connect to a database. First, you create a Secret named db-credentials containing the key password and its value. Then, in your Pod's definition, you reference this Secret to inject an environment variable named DB_PASSWORD into your application container. The application can then read the password from its environment, keeping the credential out of the image and deployment YAML.
Interview question
Which statement accurately describes how Kubernetes Secrets handle sensitive data storage?
- a.Secrets encrypt data at rest within the etcd database, ensuring it's unreadable without proper authorization.
- b.Secrets base64-encode data, which is a reversible process and not a form of encryption.Correct
- c.Secrets store data exclusively in the Pod's memory, never persisting it to the control plane's database.
- d.Secrets store data in plain text, relying solely on network policies to prevent unauthorized access.
Why? this is the answer
The card explicitly states that Secret values are stored as base64-encoded strings and clarifies that "This is encoding, not encryption, and is easily reversible." Option A is a common misconception, as Secrets do not provide encryption at rest by default.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #security
- #devops
- #secrets management
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles