Kubernetes Secrets: Managing Sensitive Data in 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.