Difference between Kubernetes ConfigMaps and Secrets | CloudTruth

Have you ever written a Dictionary in Python? Or a Hash Table in another programming language? If you have, you’ll notice a common trend in what they actually are; key/value pairs.

A key/value pair is a name and a value, for example:

• Street: Mass Drive

Street is the key and Mass Drive is the value of the key, Street

With that, the question becomes How do standard key/value pairs differ in Kubernetes?

In this blog post, you’ll learn about what Kubernetes ConfigMaps and Secrets are, and how you can use them in CloudTruth.

ConfigMaps in Kubernetes

In Kubernetes, a ConfigMap is nothing more than a key/value pair. A ConfigMap store’s non-confidential data, meaning no passwords or API keys. ConfigMaps are used for:

• Kubernetes ConfigMap environment variables
• Kubernetes command-line arguments
• Configuration files in a volume

The idea with a ConfigMap is you want the ability to pass in information at runtime to your application with the ability to keep an application portable. If you’re using a Kubernetes manifest that contains a Deployment or a Service, you may want to use the Docker image that you’re calling upon across multiple environments. With ConfigMaps, you have the ability to create environment-specific configurations vs having to create a Kubernetes manifest for each environment and putting in the values statically.

Kubernetes Dynamic ConfigMaps

By definition, Kubernetes ConfigMaps are meant to be dynamic. If they weren’t, you would simply add key/value pairs into a Kubernetes manifest. Instead, you use ConfigMaps because the values could change across environments. When you’re planning to use a ConfigMap, a few things you’ll want to ensure are:

• Will the data change across, dev, staging, and prod?
• Will there be other environments in play? Like Azure, AWS, on-prem, etc.?
• Is there an expectation that these values may change, or will they always be static?

Kubernetes ConfigMaps Example

Now that you know what ConfigMaps in Kubernetes is, let’s take a look at an example and break it down.

Below you’ll see a ConfigMap which contains:

• The kind, which is a ConfigMap
• The API version
• The metadata, which only holds the name of the ConfigMap
• The data, which holds the key/value pairs. Notice how there are two, one is for the town’s first street, and the second is for the town’s second street. Both have values, and those values are the name of the streets.

kind: ConfigMap
apiVersion: v1
metadata:
  name: myappsconfigmap
data:
  town1street: Mass
  town2street: International

Secrets in Kubernetes

When you’re thinking about secrets, it’ll essentially be any value that you don’t want the world to know about. A password, an API key, a connection string to a database, would all fall under what a secret is. When comparing secrets and ConfigMaps in Kubernetes, the key difference is the confidential data.

Both ConfigMaps and secrets store the data the same way, with key/value pairs, but ConfigMaps are meant for plain text data, and secrets are meant for data that you don’t want anything or anyone to know about except the application.

Opaque Secrets in Kubernetes

When you’re figuring out which type of secret to use in Kubernetes, there are several options.

The standard, out-of-the-box secret type for Kubernetes, is Opaque. For example, let’s say you want to create a Kubernetes secret via the command-line using the following command:

kubernetes create secret generic mynewsecret

By default, Kubernetes will use the Opaque secret type.

Secret Encryption

By default, secrets in Kubernetes are not encrypted. They’re stored in an unencrypted fashion using the API Servers etcd. This opens up a ton of security holes, which you’ll learn how you can fill in the upcoming section, CloudTruth Can Help Store Secrets.

Kubernetes Secrets Example

Taking the example code from one of the previous sections, Kubernetes ConfigMap Example, let’s create secrets with the same keys and values.

apiVersion: v1
kind: Secret
metadata:
  name: myappssecret
type: Opaque
data:
  town1street: Mass
  town2street: International

Here’s the problem with the above example; you’re still storing those secrets as plain text. The secret data can be encrypted and not in plain text via the Kubernetes EncryptionConfiguration, but that doesn’t do much for the actual values that are stored in the Secrets Kubernetes manifest. You can’t store that file in source control and you can’t keep the file only on your localhost, so what can you do?

CloudTruth Can Help Store Kubernetes ConfigMaps and Secrets

In the first section, ConfigMap Kubernetes, you learned that ConfigMaps typically store non-confidential information, like a street name or a storage volume name. Even though that’s the case, you still need a way to store Kubernetes Secrets to pass into a Kubernetes application configuration. To do that, you need a place to store those Kubernetes Secrets.

That’s where CloudTruth comes into play.

With CloudTruth Kubernetes integration, you can create a new parameter via a project that you dedicate to your Kubernetes application. With that new parameter, you can specify that you want it to be a secret. That means CloudTruth will not store this parameter as plain text and it will encrypt the parameter.

After clicking the blue Create Parameter button, you can give your parameter a value.

Once you click the blue Save button, you can see that the parameter was saved in an encrypted fashion.

If you want to see the value to confirm it, you can click the Show Secrets button and the value will appear in plain text.

Getting Started With CloudTruth

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