Kubernetes secrets are objects that store and manage sensitive data inside your Kubernetes cluster. One mistake developers often make is storing sensitive information like database passwords, API credentials, etc in a settings file in their codebase. This is very bad practice (hopefully for obvious reasons). Most developers know this, but still choose the option because it's easy.
Fortunately, if you're running your application in a Kubernetes cluster, managing that sensitive data the right way is easy. This guide will provide an overview to Kubernetes Secrets, including how to create, store, and use secrets in your applications.
Creating secrets, like most Kubernetes operations, is accomplished using the kubectl command. Fortunately, there are a few ways to create secrets, and each are useful in different circumstances.
Let's first look at the secret we want to create. Remember that the secret is an object that contains one or more pieces of sensitive data. For our example, let's imagine we want to create a secret, called database, that contains our database credentials. It will be constructed like this:
database
- username
- password
Create a secret from files
Suppose you have the following files: username and password. They might have been created like this:
While this is directly applicable, I'll add this as a note because it could be useful. Sometimes we'll need to copy secrets from one cluster or namespace to another. Here's a quick example:
Secrets aren't all that helpful until they're attached to a pod. In order to actually use the secrets they must be configured in the pod definition.
There are two primary ways two use secrets: as files and as environment variables.
Attaching secrets as files
See the following pod config:
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: web
image: web:1.0.0
volumeMounts:
- name: database-volume
mountPath: "/etc/secrets/database"
readOnly: true
volumes:
- name: database-volume
secret:
secretName: database
There are two important blocks to take note of. First, let's look at the volumes block. We set the name of the volume and specify which secret we want to use. Note that this is set at the pod level, so it could be used in multiple containers if the pod were to define them.
Next we'll look at how the volume is mounted onto the container using volumeMounts. We'll specify which volume we want to use, and set the mount path to /etc/secrets/database.
Inside of the container, we can run an ls on /etc/secrets/database and find that both the username and password files exist.
Attaching secrets as environment variables
Secrets can also be used inside of containers as environment variables. Check out the same config but with secrets attached as environment variables instead of volumes:
Both volumes and environment variables are perfectly acceptable ways to access secrets from inside your containers. The major difference is that environment variables can only hold a single value, while volumes can hold any number of files—even nested directories. So if your application requires access to many secrets, a volume is a better choice for organization and to keep the configs manageable.
I know some readers will not be using Python containers, but the purpose of this step is to provide a conceptual understanding of how secrets can be used from within the container.
Assuming you've followed the first two steps, you should now have a database secret that contains a username and password.
Reading secrets from a volume
If we've mounted the secret as a volume, we can read the secret like this:
with open('/etc/secrets/database/password, 'r') as secret_file:
database_password = secret_file.read()
Grabbing the secret file is as easy reading from a file. Of course, you'd probably abstract this code and add error handling and defaults. After all, this is much more pleasant: get_secret('database/password').
Reading secrets from environment variables
This is even more straight forward, at least in Python. You can read the secret just as you would any other environment variable:
import os
database_password = os.environ.get('DATABASE_PASSWORD')
I hope this overview of Kubernetes secrets was helpful. By now, you should have a good understand of what Kubernetes secrets are and how to use them. If you have questions, please ask in the comments below or head over to the Kubernetes secrets documentation.
There are many reasons you might want to copy Kubernetes secrets from one cluster to another. In recent months, I had to migrate to a new GKE cluster in order to get some new functionality.