Kubernetes ConfigMaps and Secrets

What are ConfigMaps and Secrets?

In Kubernetes, **ConfigMaps** and **Secrets** are used to store configuration data and sensitive information (such as passwords, tokens, etc.) separately from the application code. Both are key to maintaining a clean separation between application logic and environment-specific configurations.

ConfigMaps

A **ConfigMap** is an API object used to store non-sensitive configuration data in key-value pairs. ConfigMaps can be consumed by Pods as environment variables, command-line arguments, or configuration files.

Creating a ConfigMap

You can create a ConfigMap in several ways: from a file, from literal values, or from a directory. Here’s an example of how to create a ConfigMap from a file.

kubectl create configmap my-config --from-file=config.txt

Using a ConfigMap in a Pod

Once created, you can use a ConfigMap in a Pod by referencing it in the Pod's specification. Here's an example of using a ConfigMap as environment variables in a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: myimage
      envFrom:
        - configMapRef:
            name: my-config

This example shows how to use a ConfigMap in a Pod by referencing the `my-config` ConfigMap and injecting its key-value pairs as environment variables into the container.

Secrets

A **Secret** is similar to a ConfigMap, but it's specifically designed to store sensitive information such as passwords, tokens, SSH keys, etc. Secrets are encoded in base64 to obscure the data, though they are not encrypted by default.

Creating a Secret

You can create a Secret using the `kubectl create secret` command. Here's an example:

kubectl create secret generic my-secret --from-literal=password=mysecretpassword

Using Secrets in a Pod

Just like ConfigMaps, Secrets can also be consumed in Pods as environment variables or mounted as volumes. Here’s an example of using a Secret in a Pod as an environment variable:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: myimage
      env:
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: password

In this example, the value of the `password` key from the `my-secret` Secret is injected as the environment variable `SECRET_PASSWORD` inside the container.

Security Considerations

While **Secrets** provide a way to store sensitive information, they are not encrypted by default. For enhanced security, you can configure Kubernetes to use encrypted storage for Secrets using external tools or cloud provider solutions.

Additionally, Kubernetes offers RBAC (Role-Based Access Control) to restrict access to sensitive data stored in Secrets. Ensure that only authorized users or services have access to sensitive information.

Conclusion

ConfigMaps and Secrets are crucial components for separating configuration and sensitive data from application code. ConfigMaps help manage non-sensitive settings, while Secrets provide a way to securely store sensitive information. By using these resources in Kubernetes, you can build scalable and maintainable applications.

In the next lesson, we will dive into **Kubernetes Volumes** for persistent data storage in your Pods.

ConfigMaps and Secrets