The current way of storing Kubernetes secrets isn’t great for a few reasons:
- The default way of storing Kubernetes secrets is in an unencrypted fashion in
- You have to create an entirely new manifest to create secrets or use the CLI
- You have to write extra code to retrieve the secrets
Although it works, it can work much better.
For Developers and DevOps Engineers, it’s a hassle trying to figure out how secrets are going to be stored, where they’ll be pulled from, and how they’ll be implemented. One of the goals with Kubernetes is to relieve these types of issues, not add to them.
In this blog post, you’ll learn how easy Kubernetes secrets are with CloudTruth.
Why Kubernetes Secrets Are A Pain
Managing passwords, API keys, and other secrets is a big deal. It can literally be the make or break between an application running normally and a company being on the headline news because of a security breach. Because of this, managing secrets for Kubernetes needs to be easier for everyone involved, including engineers and leadership teams.
Although Kubernetes is great for a lot of different development and DevOps aspects, storing and retrieving secrets is a major pain point for teams. The first major concern is by default, Kubernetes secrets are not encrypted. They’re stored in the
etcd datastore, which is essentially the Kubernetes database. The last thing you want is for secrets to be stored in a plain text fashion.
The second major concern is where you store the manifests for the secrets. Let’s say you create a Secrets Kubernetes manifest for a MySQL deployment. you’ll most likely need a few secrets including:
- A MySQL password
- A MySQL root password
Although you can store these secrets in Kubernetes, where are you going to store the Kubernetes manifest? You can’t store the manifest in GitHub because that would be storing passwords in plain text. You can’t keep the manifest local because then no one else would be able to use it.
What can you do?
Secrets For Kubernetes
The way to implement easy Kubernetes secrets for an application running inside of Kubernetes is usually the same approach, so let’s think about a generic method by using MySQL for explanation purposes.
Take a look at the Kubernetes manifest below, particularly lines 24-43. This is what a manifest will look like without CloudTruth.
apiVersion: apps/v1 kind: Deployment metadata: name: wordpress-mysql labels: app: wordpress-mysql spec: selector: matchLabels: app: wordpress-mysql tier: mysql strategy: type: Recreate template: metadata: labels: app: wordpress-mysql tier: mysql spec: containers: - image: mysql:8.0 name: mysql env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-pass key: MYSQL_ROOT_PASSWORD - name: MYSQL_USER valueFrom: secretKeyRef: name: mysql-pass key: MYSQL_USER - name: MYSQL_PASSWORD valueFrom: secretKeyRef: name: mysql-pass key: MYSQL_PASSWORD - name: MYSQL_DATABASE valueFrom: secretKeyRef: name: mysql-pass key: MYSQL_DATABASE ports: - containerPort: 3306 name: mysql
The problem with this approach is that:
- You have to create Kubernetes Secrets via the command line or through a Secrets manifest
- Once you create the secrets, you have to ask yourself where you’ll store them. For example, if you create a Kubernetes Secrets manifest, where are you going to store .it? You can’t push it to GitHub because that means the Secrets will be in plain text.
- You have to do extra work and bring in extra implementations to make Secrets work.
With CloudTruth, all you have to do is run a CloudTruth CLI command and the Secrets get pulled from CloudTruth.
For example, below is what the manifest looks like with CloudTruth:
apiVersion: apps/v1 kind: Deployment metadata: name: labels: app: spec: selector: matchLabels: app: tier: mysql strategy: type: Recreate template: metadata: labels: app: tier: mysql spec: containers: - image: : name: mysql env: - name: MYSQL_ROOT_PASSWORD value: - name: MYSQL_USER value: - name: MYSQL_PASSWORD value: - name: MYSQL_DATABASE value: ports: - containerPort: 3306 name: mysql
Not only is it less code in your manifest, but it’s a much simpler approach. The parameters inside of the curly brackets, for example,
, are stored in CloudTruth along with values.
When you create a new parameter in CloudTruth, you can choose from:
Taking the example manifest above, let’s think about how to store the
. Ultimately, you want to store the parameter as a secret. That way it’s fully encrypted at rest and in transit.
Once the secret is stored in CloudTruth, it doesn’t come up as plain text even on the CloudTruth portal. However, you can click the blue Show Secrets button and reveal the value of the secret if you need to see it.
Storing and retrieving secrets in CloudTruth is ridiculously straightforward. You don’t have to create new manifests, figure out where to store them, and figure out how to not only encrypt the secrets but secure the manifests themselves. With CloudTruth, you simply store the secrets within CloudTruth and retrieve them in a secure fashion when needed.
If you’d like to get started with CloudTruth today, there is a free forever version here.
Here’s a short video on this topic: