Kubernetes 101: Secret and ConfigMap
Written by 8grams
Published at July 10, 2023
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.
Type of Secret | Description | Fields | Primary Use |
---|---|---|---|
Opaque | Default type. Can store arbitrary secret data. | data | Storing custom data |
kubernetes.io/service-account-token | Automatically created by Kubernetes and attached to service accounts. | token, ca.crt, namespace | Authentication with Kubernetes API |
kubernetes.io/dockercfg | Holds Docker configuration information. | .dockercfg | Legacy Docker authentication |
kubernetes.io/dockerconfigjson | Holds Docker configuration information. | .dockerconfigjson | Modern Docker authentication |
kubernetes.io/basic-auth | Holds credentials for basic authentication. | username, password | Authentication to services using basic authentication |
kubernetes.io/ssh-auth | Holds SSH authentication credentials. | ssh-privatekey | SSH authentication |
kubernetes.io/tls | Holds a certificate and its corresponding key. | tls.crt, tls.key | TLS-enabled services |
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.
Attribute | Secret | ConfigMap |
---|---|---|
Stored Data | Sensitive information, such as passwords, OAuth tokens, and ssh keys | Non-sensitive configuration data in the form of key-value pairs |
Encoding | Base64 encoding | No encoding needed |
Usage | Used by Pods to access sensitive information | Used by pods to access configuration settings |
Security | Kept private and used to control access to sensitive data | Publicly available to any application or user who has the necessary permissions |
Example | API keys, database passwords | Application settings, feature flags |
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
andpassword
. 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 forlog_level
andlog_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!