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:
Create a secret from files
Suppose you have the following files: username and password. They might have been created like this:
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:
- name: web
- name: database-volume
- name: database-volume
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.
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:
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.