February 21, 2022
What’s the Difference between a Kubernetes ConfigMap and a Secret?
Written by: Michael Levan
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
Mass Drive is the value of the key,
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:
kind, which is a
- 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.
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.
Tag(s): Kubernetes , Configuration Management