Kubernetes 101: Secret and ConfigMap

Introduction to Kubernetes Secrets

Kubernetes Secrets are designed to store and manage sensitive information. Such sensitive information could include tokens, passwords, or ssh keys. Instead of storing this information within an application or its associated source code, it is often stored in Secrets to enhance the security.

Secrets come in several types: Opaque, kubernetes.io/service-account-token, kubernetes.io/dockercfg, kubernetes.io/dockerconfigjson, kubernetes.io/basic-auth, kubernetes.io/ssh-auth, and kubernetes.io/tls. Each of these is used for different scenarios, providing a flexible way to handle various types of sensitive data.

Every Secret holds a data and a stringData field. The data field is used to store arbitrary data, encoded using base64. The stringData is a write-only convenience field, providing a way to specify non-binary information directly, which will be base64 encoded by Kubernetes.

Secrets in Kubernetes are stored in etcd and transmitted to Pods over a network connection, both of which are secured by the Kubernetes API server. Kubernetes also supports encryption at rest for Secret data, adding an extra layer of security.

The lifecycle of a Secret involves its creation, usage by a Pod, and eventual deletion. When a Secret is deleted, it is immediately unavailable to new Pods, but existing Pods can still access it until they are restarted.

However, Secrets do have limitations. One of them is that they are restricted to a maximum size of 1MB. Another is that, although they are more secure than storing sensitive data in Pod specs or images, they still are not a comprehensive solution for managing sensitive data.

Types of Secrets

Kubernetes supports several types of Secrets to accommodate different use cases. Each type of Secret has a specific purpose and is used in different scenarios. Let's go through some of these types:

Opaque
The Opaque is the default Secret type. You can use it to store arbitrary Secret data. These Secrets don't have any specific constraints imposed by Kubernetes.

Example:

kubernetes.io/service-account-token
These are automatically created by Kubernetes and attached to service accounts. They're used to authenticate applications that want to communicate with the Kubernetes API server. The data field for these Secrets includes a token and a Kubernetes API server root certificate.

kubernetes.io/dockercfg and kubernetes.io/dockerconfigjson
These types of Secrets are used to hold Docker configuration information. The dockercfg Secret type is used for Docker's legacy configfile format, and dockerconfigjson is used for Docker's newer config.json format. They both contain the necessary credentials for pulling images from private Docker repositories.

kubernetes.io/basic-auth
This type of Secret can store credentials for basic authentication. It contains two fields: username and password. These are often used when interacting with REST APIs that require basic authentication.

Example:

kubernetes.io/ssh-auth
These Secrets are used to hold SSH authentication credentials. They contain a single ssh-privatekey field for the private SSH key. This can be useful when you need to interact with a service that requires SSH authentication.

kubernetes.io/tls
These are used to store a certificate and its corresponding private key. These are typically used for TLS-enabled services. This type of Secret expects two fields: tls.crt and tls.key.

Example:

Remember that all secret data should be base64 encoded before being included in the Secret definition. Kubernetes will decode this data when it is used.

ConfigMap

A Kubernetes ConfigMap is an API object used to store non-sensitive configuration data in key-value pairs. The primary purpose of a ConfigMap is to externalize configuration so your applications are portable. You can use ConfigMaps for environment-specific configurations and application configurations.

Like Secrets, ConfigMaps are stored in etcd and have their lifecycle managed by Kubernetes. The lifecycle involves creation, usage by Pods, and eventually an update or deletion.

A ConfigMap's data is stored in the data field, and it can store simple key-value pairs to more complex configurations like JSON or YAML files.

Unlike Secrets, ConfigMaps are not encrypted at rest or in transit unless you use third-party tools or services. They also have a size limitation of 1MB.

Secret vs ConfigMap

Although Secrets and ConfigMaps serve different purposes in Kubernetes, they share several similarities. Both are stored in etcd and have a size limitation of 1MB. They have a similar lifecycle, from creation to deletion, and they both use the data field to store information.

However, the differences between Secrets and ConfigMaps are vital. Secrets are meant to store sensitive data and are encrypted in transit and at rest, whereas ConfigMaps are used for non-sensitive configuration data and are not encrypted.

Secrets and ConfigMaps as Environment Variables

Both Secrets and ConfigMaps can be used to define environment variables in a Pod. For instance, you can define a Secret with an API key and then reference that Secret when defining environment variables for your Pods. The same applies to ConfigMaps.

Consider this example for Secrets:

And then use the secret as an environment variable:

The same can be achieved with ConfigMaps. First, define a ConfigMap:

Then, use the ConfigMap as environment variables in your Pod:

This ensures the secrets and configurations are kept separate from the application code and can be changed independently of the application code.

Container Startup Commands with Secrets and ConfigMaps

You can use Secrets and ConfigMaps to set command-line arguments for your containers at startup. This could be useful if you want to pass a secret token or a configuration parameter to your application without hardcoding it into your application code.

The following example illustrates how you can use a Secret in a container’s command-line argument:

Similarly, ConfigMap can be used in the command line:

Secret and ConfigMap Management

Creating Secret & ConfigMap

This Secret manifest is divided into several parts:

• apiVersion: This indicates the version of the Kubernetes API you're using to create this object.
• kind: This indicates the type of the Kubernetes object you're creating. In this case, it's a Secret.
• metadata: This contains metadata about the Kubernetes object, like its name and namespace. In this case, the name of the Secret is mysecret.
• type: This specifies the type of Secret. Opaque is the default and most flexible Secret type, as it allows for arbitrary key-value pairs.
• data: This is where the actual secret data is stored. In this case, there are two pieces of data: username and password. The values are base64-encoded strings.

Next, let's look at a ConfigMap manifest.

The ConfigMap manifest also has several parts:

• apiVersion: Similar to the Secret, this indicates the version of the Kubernetes API you're using to create this object.
• kind: This specifies the kind of the Kubernetes object you're creating. In this case, it's a ConfigMap.
• metadata: This contains metadata about the Kubernetes object. In this case, the name of the ConfigMap is myconfigmap.
• data: This is where the actual configuration data is stored. It's similar to the data in Secrets, but it's not base64-encoded. In this example, it holds configuration for log_level and log_location.

To create a Secret, you can use the following command:

~$ kubectl apply -f secret.yaml

To create a ConfigMap, use the following command:

~$ kubectl apply -f configmap.yaml

Reading Secrets and ConfigMaps

To get information about a specific Secret or ConfigMap, use the following commands:

~$ kubectl get secret mysecret -o yaml
~$ kubectl get configmap myconfigmap -o yaml

To list all Secrets or ConfigMaps:

~$ kubectl get secrets
~$ kubectl get configmaps

Updating Secrets and ConfigMaps

You can update Secrets and ConfigMaps using the kubectl apply command with an updated YAML file. This will apply the changes specified in the file to the existing Secret or ConfigMap.

If you want to update a specific field without changing the whole configuration, you can use the kubectl patch command. Here's an example of patching a ConfigMap:

~$ kubectl patch configmap myconfigmap -p '{"data":{"log_level":"Info"}}'

Deleting Secrets and ConfigMaps

To delete a Secret or a ConfigMap, use the following commands:

~$ kubectl delete secret mysecret
~$ kubectl delete configmap myconfigmap

This will remove the Secret or ConfigMap from the Kubernetes cluster. Be aware that any pods or other resources that were using this Secret or ConfigMap may be affected.

Always make sure to verify the impact of the deletion before proceeding with these operations.

About 8grams

We are a small DevOps Consulting Firm that has a mission to empower businesses with modern DevOps practices and technologies, enabling them to achieve digital transformation, improve efficiency, and drive growth.

Ready to transform your IT Operations and Software Development processes? Let's join forces and create innovative solutions that drive your business forward.

Subscribe to our newsletter for cutting-edge DevOps practices, tips, and insights delivered straight to your inbox!