Join our - Lead the Future of API Dev: A New Approach with Blackbird -Webinar on September 19thRegister Now

Back to blog
KUBERNETES SECRETS, KUBERNETES

Managing Configurations and Secrets in Kubernetes: ConfigMaps and Secrets

Israel Tetteh
November 15, 2023 | 11 min read

Configurations and secrets play vital roles in the successful operation of any application. Kubernetes provides dedicated resources, namely ConfigMaps and Secrets, to effectively manage these elements within a containerized environment. Understanding how to leverage ConfigMaps and Secrets is essential for efficient application deployment and maintenance in Kubernetes.

In this article, we will discuss the concepts of ConfigMap and Secrets in Kubernetes, explore how to work with ConfigMaps, learn about managing secrets, and understand how to use ConfigMap and secrets in deployments. Then, we will delve into best practices for ConfigMaps and Secrets.

What is a Kubernetes ConfigMap?

The Kubernetes ConfigMap is a Kubernetes API resource that lets you store non-confidential configuration data for your applications. It allows you to decouple configuration from your application code, allowing you to change configuration settings without having to edit and relaunch your program.

ConfigMaps stores data in a key-value format, making it an excellent choice for environmental setups, endpoint URLs, and various application configuration parameters. ConfigMaps abstract these settings, making the system more modular and flexible as a whole. ConfigMaps allow applications to access necessary configurations, facilitating a more efficient method of handling configurations apart from the main logic of the program.

When a ConfigMap is utilized, files mounted directly into the container or environment variables can be used by the program to access the stored configurations. By separating the application code from the configuration, best practices for managing configuration data in a Kubernetes context are encouraged, and modularity is improved.

What is a Kubernetes Secret?

A Kubernetes Secret is an object that stores and manages sensitive information like passwords, API keys, tokens, or any other secret data. Secrets, like ConfigMaps, enable you to segregate sensitive information from your application code. Conversely, secrets are built explicitly for storing secret data and offer additional security safeguards.

Similar to ConfigMaps, secrets are key-value pairs with base64 encoding added for an extra degree of protection. Base64 encoding obscures the data, making it more difficult for unauthorized users to decode, even though it doesn't offer encryption. By acting as a disincentive, this encoding technique makes sure that private information is kept hidden.

Kubernetes offers a safe way to manage private data inside the cluster by utilizing Secrets. Applications retrieve sensitive data through file mounts or environment variables when accessing Secrets, just like they do with ConfigMaps.

What are the differences between ConfigMaps and Secrets?

  1. ConfigMaps are typically used for non-sensitive configuration data, while Secrets are used for storing sensitive information.
  2. ConfigMaps stores data as key-value pairs, whereas Secrets stores data as base64-encoded data, thereby ensuring an additional layer of security.
  3. ConfigMaps are typically used to store configuration data, such as environment variables, while Secrets store sensitive data, such as passwords and API key.

Working with ConfigMaps

Working with Kubernetes ConfigMaps allows you to separate configuration details from containerized apps. ConfigMaps are used to hold non-sensitive configuration data that may be consumed as environment variables by containers or mounted as configuration files. Here are some Kubernetes operations for interacting with ConfigMaps:

  • Creating a ConfigMap: To create a ConfigMap, you can define it in a YAML file or use the
    `kubectl create configmap`
    command. Here's an example YAML definition:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
key1: value1
key2: value2
```

The above YAML file, when deployed in a cluster, will create the ConfigMap resource and data.


  • Using environment variables with ConfigMaps: A ConfigMap’s data can be injected into containers as environment variables. To do this, specify the env field with the desired environment variables in the deployment YAML.
```
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
env:
- name: KEY1
valueFrom:
configMapKeyRef:
name: my-configmap
key: key1
- name: KEY2
valueFrom:
configMapKeyRef:
name: my-configmap
key: key2
```

The above YAML configuration enables the application inside the container to access configuration data through the environment variables. The ConfigMap allows centralized management of configuration values, decoupling them from the application code.

  • Mounting ConfigMaps as volumes: ConfigMaps can also be mounted as files in containers. To do this, define a volume and mount it within the container as seen in the YAML configuration file below. By doing this, the ConfigMap data is made available to the container as a file or directory at the specified mount path
    `/etc/config`
    . The application executing inside the container can access and use the contents of the ConfigMap.
```
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
volumes:
- name: config-volume
configMap:
name: my-configmap
containers:
- name: my-container
image: my-image
volumeMounts:
- name: config-volume
mountPath: /etc/config
```
  • Updating ConfigMaps: ConfigMaps can be updated using the
    `kubectl edit configmap`
    command or by updating the YAML definition and applying the changes. Existing pods that reference the ConfigMap will immediately receive the updated data. Below is a code example for updating existing data in a ConfigMap.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: example-configmap
data:
key1: value1
key2: updated_value2
```

Replace

`example-configmap`
with the name of the ConfigMap you want to update.

  • Deleting ConfigMaps: To delete a ConfigMap, use the
    `kubectl delete configmap`
    command followed by the ConfigMap's name.

Managing Secrets

Secret management in Kubernetes is critical for securely storing sensitive data such as API keys, certificates, and passwords. Kubernetes includes a resource named "Secrets" that allows you to manage and distribute sensitive data to your apps. Here are some Kubernetes operations for handling secrets:

  • Creating a Secret: To create a Secret, you can define it in a YAML file or use the
    `kubectl create secret`
    command. Here's an example YAML definition:
```
apiVersion: apps/v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
username: xxxxxx
password: xxxxxxxx
```

The Kubernetes cluster will securely store the secret data when applying the above YAML configuration. The data will only be accessible to approved apps or services within the cluster, ensuring the security of sensitive information. Note that the values for sensitive data are base64-encoded.

  • Using Secrets as environment variables: Similar to ConfigMaps, Secrets can be used as environment variables within containers. To do this, specify the desired environment variables in the deployment YAML:
```
apiVersion: apps/v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: my-secret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: my-secret
key: password
```

When the above YAML file is applied, the container within the Pod will have access to the "USERNAME" and "PASSWORD" environment variables. The applications or processes running within the container can use these environment variables to retrieve sensitive data, such as the username and password stored in the Secret.

  • Mounting Secrets as volumes: Secrets can also be mounted as files in containers. To do this, define a volume and mount it within the container just like I did in the YAML configuration below:
```
apiVersion: apps/v1
kind: Pod
metadata:
name: my-pod
spec:
volumes:
- name: secret-volume
secret:
secretName: my-secret
containers:
- name: my-container
image: my-image
volumeMounts:
- name: secret-volume
mountPath: /etc/secret
readOnly: true
```

When the YAML file above is applied, the secret

`my-secret`
is mounted as a volume inside the container. The Secret's contents, such as keys and values, are represented as files on the mounted volume. Applications or processes running inside the container can access the files in the Secret drive, allowing them to read the sensitive information stored there.


Updating Secrets: Secrets can be updated using the

`kubectl edit secret`
command or by updating the YAML definition and applying the changes. To update a Secret, you need to create a new Secret with the updated data and the same name as the existing Secret. Kubernetes will automatically update the existing Secret with the new values. Here's an example YAML code for updating a Secret:

```
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
username: new_base64_encoded_username
password: new_base64_encoded_password
```

Replace

`my-secret`
with the name of the Secret you want to update. The
`type: Opaque`
indicates that the Secrets contains arbitrary data, and
`data`
includes the updated base64-encoded value.


Deleting Secrets: To delete a Secret, use the

`kubectl delete secret`
command followed by the Secret's name.

Using ConfigMap and Secrets in Deployment

When using a Kubernetes Deployment to deploy an application, you can utilize ConfigMaps and Secrets to provide configuration data and sensitive information to your application containers. Below is an example of how ConfigMaps and Secrets can be used within a Deployment:

```
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image
env:
- name: CONFIG_VALUE
valueFrom:
configMapKeyRef:
name: my-configmap
key: key1
- name: SECRET_VALUE
valueFrom:
secretKeyRef:
name: my-secret
key: username
volumeMounts:
- name: config-volume
mountPath: /etc/config
- name: secret-volume
mountPath: /etc/secret
volumes:
- name: config-volume
configMap:
name: my-configmap
- name: secret-volume
secret:
secretName: my-secret
```

Best Practices for ConfigMap and Secret Management

  1. Limiting access to ConfigMaps and Secrets: Apply the principle of least privilege by ensuring only the necessary entities have access to ConfigMaps and Secrets. Use Kubernetes RBAC (Role-Based Access Control) to define appropriate access controls.
  2. Encrypting Secrets at Rest: Enable encryption at rest for Kubernetes secrets. This ensures that secrets are stored securely and cannot be easily accessed if the underlying storage is compromised.
  3. Rotating Secrets: Regularly rotate secrets to mitigate the impact of potential breaches. Kubernetes provides mechanisms to automate secret rotation, such as external tools or custom scripts.
  4. Using tools for managing ConfigMaps and Secrets: Leverage tools like Helm, Kubernetes Operators, or custom scripts to automate the creation, update, and deletion of ConfigMaps and Secrets. This streamlines the management process and reduces the potential for human error.
  5. Avoid hard-coding: Utilize ConfigMaps and Secrets to externalize configurations and sensitive information instead of hard-coding them within the application code or container images. This ensures flexibility and enhances security.

Conclusion

Effective configuration and secret management are critical for the successful functioning and security of Kubernetes applications. ConfigMaps and Secrets are solid tools for storing and disseminating configuration and sensitive data, respectively. Understanding their functions and implementing best practices will help you simplify configuration and secret management, assuring smooth deployments and the integrity of your applications.

Remember that ConfigMaps and Secrets are significant resources that help DevOps teams achieve a more secure and efficient Kubernetes application deployment process. Organizations can easily construct robust and scalable containerized apps by exploiting their strengths and following best practices.

Telepresence

Simplify developer collaboration and bridge the gap between local and remote Kubernetes development environments