How to: Easy Kubernetes Secrets

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 etcd
• 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.

CloudTruth Parameters

When you create a new parameter in CloudTruth, you can choose from:

• Plain-text
• Secret

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.

Wrapping Up

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.

Check out more details on the CloudTruth Kubernetes integration and open source Kubernetes operator.

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: