Kubernetes Secrets and Vault: How CloudTruth Helps

Managing secrets in one location for resources and services to retrieve them is a pain. Whether those resources and services are in the cloud or on-prem, you need an easy way to give applications the data they need. That data can be anything from secrets to parameters and environment variables.

In this blog post, you’ll learn about a few key ways to manage secrets in today’s world and how CloudTruth can make secret management easier.

Kubernetes Secrets

If you’ve ever deployed an application that required perhaps a password to connect to a database, an API key for a POST request, or another form of login that wasn’t plain text, you most likely have come across Kubernetes Secrets. If you have, you may be thinking to yourself what is secret management in Kubernetes?

Simply put, secret management is a way to store sensitive data that you don’t want in plain text. For example, you wouldn’t want a password to be passed around between environments if it wasn’t encrypted. Otherwise, an attacker could consume that data and perhaps negatively impact your application.

Kubernetes secrets are no different. When you have a secret in Kubernetes, it’s all about giving the value of the secret to the application that needs it. For example, perhaps you have an application that needs a MySQL connection string. Of course, you wouldn’t want that connection string as plain text. Instead, you’d want to store it as a secret for the application to consume.

There are a few ways to manage and create Kubernetes secrets, which you’ll learn about in the upcoming two sections.

Secrets YAML

When creating a Kubernetes secret YAML, it’ll look like any other Kubernetes manifest. You’ll have your API version, the kind, and then the data.

Below is an example of creating a Secret manifest.

apiVersion: v1
kind: Secret
metadata:
    name: password
type: Opaque
data:
    app-user: mike
    app-password: cGFzc3dvcmQ=

The concern with the YAML file storing a secret is; where are you going to store it? You can’t store it in source control because it’s plain text. You can’t save it locally because that doesn’t help the rest of your team.

What do you do?

Secrets From the Command Line

You can also create and store secrets from the command line.

To create a secret from a literal value, you’ll have to do the following:

• Pass in a name for the secret. For example, the name of the secret below is password
• Use the —from-literal parameter
• Give a key/value pair. For example; password=test123

kubectl create secret generic password --from-literal password=test123

To retrieve a secret, the command will look like kubectl get secret value

For example, to retrieve the secret called password, it would look like:

kubectl get secret password

The Encryption Concern

Although Kubernetes secrets are not in plain text, the default secret object, Opaque, is not encrypted at rest by default. Kubernetes secrets by default are stored in an unencrypted fashion in the etcd data store. Anyone with API access to the Kubernetes control plane can see and retrieve those secrets. What that essentially means is anyone with the kubeconfig can see, retrieve, and edit secrets.

The Usability Concern

As you can see from the above, both the command-line and the YAML manifest are easy from a technical perspective, but it’s a lot to manage. You’ll have to create and manage a bunch of Kubernetes secret manifests or have a bunch of kubectl create secret commands stored somewhere in source control so the rest of the team can use them.

It becomes quite cumbersome.

Kubernetes Secrets and Vault

It’s no secret that HashiCorp is a one-stop-DevOps-shop when it comes to infrastructure-as-code and deployments. Another awesome piece of software that HashiCorp has is Vault. Vault is a way to manage secrets, API keys, and other sensitive data to be stored and retrieved later by your applications.

Vault is great with secrets, but it’s not really geared towards other types of configuration data (parameters, environment variables, values to be passed in at runtime, etc.). The truth is, there’s a ton of data that your applications need to consume that isn’t sensitive.

Let’s take a Kubernetes manifest as an example. A lot of Kubernetes manifests are pretty universal and generic. In reality, you shouldn’t have to create a new manifest for each Kubernetes deployment or service. Instead, you should have the ability to store parameters and/or environment variables in one location to ensure you can create reusability for all of your software and applications.

HashiCorp Vault Server

Several organizations that want to save costs typically deploy HashiCorp Vault servers. Organizations also do this if they want to control the data throughout its entire lifecycle. The servers can be on-prem running bare metal or virtualized, or they can be in the cloud running in an Azure Virtual Machine or an EC2 instance.

The problem with this approach is you have an entirely new environment to manage. Servers, networks, access, permissions, and uptime must now be thought about. This may not be possible for small and medium organizations that have a smaller engineering team. Storing configuration data should be easy.

HashiCorp Vault Helm Chart

One of the interesting ways to deploy Vault is with a Vault Helm Chart. You can run the HashiCorp Vault service right on your Kubernetes cluster. Although this is an awesome feature, the problem is that it makes you have to manage another Helm Chart and configuration data because if the cluster goes down, you have to re-deploy Vault. That means secrets will be unavailable for a period of time. With a SaaS-style platform, you won’t have to worry about that headache.

Vault Support In The Cloud

At the time of writing this blog post, HashiCorp Vault for the cloud only supports AWS and in the us-west-2 region.

What CloudTruth Is Solving

There are a lot of secret management platforms that are out there, and they’re incredibly good. Some are built right into Kubernetes itself and others are 3rd-party software. What CloudTruth ultimately wants to solve is the complexity of centralizing secrets, environment variables, and parameters. Having one location to store every piece of environment data, for any cloud and any application should be easy. It should be the least of your concerns and that’s what CloudTruth is aiming for.

We don’t want you to have to spin up servers that you have to manage or be locked into a single cloud. We want you to have a fully managed SaaS platform for all of your configuration data. CloudTruth is creating a true way to store AND retrieve your secrets, environment variables, and parameters from anywhere. The anywhere is anything on-prem, in any cloud, in any region, and for every application that you write.

Secrets Management in 2022

This isn’t meant to be a blog post about Kubernetes secrets vs Vault or why CloudTruth is better because, at the end of the day, each tool has its place. Regardless of which option you go with, you ultimately want the ability to make your life, and the rest of the team’s life, easier. You have to worry about writing code, shipping code, fixing bugs, and giving your customers the best experience possible. The last thing that you should have to worry about is if your secrets are safe or if you’ll always be able to retrieve them.

With CloudTruth, we’re not reinventing the wheel on secret management. We’re simply making your life easier with one location to not only store your secrets in an encrypted fashion but to retrieve them (in an in-transit encrypted fashion) from any cloud or on-prem environment to be used by your software.

Getting Started With CloudTruth

If you’d like to get started with CloudTruth today, you can try it for free at the link here.