Mounting ConfigMaps and Secrets as Volumes

1. Why Mount Configuration as a Volume?

Before we dive into the "how," let's discuss the "why." You can provide configuration to a Pod either by mounting it as a volume (files) or by injecting it as environment variables. While both are useful, volume mounting is often the superior approach for several reasons.

Let's explore the key advantages, which are critical from a platform management perspective.

As you just read, the two main advantages are:

1. Dynamic Updates without Pod Restarts: When a ConfigMap or Secret that is mounted as a volume is updated, the files inside the Pod's volume are automatically updated by the kubelet. Most applications capable of reading configuration from the filesystem can detect these changes and reload their configuration on the fly. This allows you to change application settings without requiring a Pod restart or a full deployment cycle, a significant benefit for uptime and operational agility. In contrast, environment variables are only injected when a container starts and do not change during its lifetime.

2. Enhanced Security for Secrets: When you mount a Secret as a volume, Kubernetes uses an in-memory filesystem (tmpfs). This means the secret data is never written to the node's persistent disk, reducing the risk of exposure. Environment variables, on the other hand, can be inadvertently leaked through application logs, crash dumps, or even introspection tools (kubectl exec). For this reason, mounting is the recommended practice for sensitive data.

2. Mounting a ConfigMap as a Volume

Let's put this into practice. Mounting a ConfigMap involves two main steps within your Pod or Deployment manifest:

1. Define a Volume: In the spec.volumes section of your Pod, you define a new volume and specify that its source is a ConfigMap by name.
2. Mount the Volume: In the spec.containers[].volumeMounts section for a specific container, you reference the volume by name and provide the mountPath where the files should appear inside the container.

Let's look at a concrete example.

Let's break down the key parts from the example you just reviewed:

First, assume we have a ConfigMap like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database.host: "mysql.prod.svc.cluster.local"
  feature.flags: "enable-new-dashboard,disable-legacy-api"

Now, here is the relevant part of the Pod manifest to mount it:

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: busybox
    # The application will read its config from /etc/config
    command: [ "/bin/sh", "-c", "sleep 3600" ] 
    volumeMounts:
    - name: config-volume   # Step 2: Reference the volume by name
      mountPath: /etc/config # Mount it at this path inside the container
  
  volumes:
  - name: config-volume      # Step 1: Define a volume with a name
    configMap:
      name: app-config       # Point it to our ConfigMap

After applying this manifest, if you exec into the pod, you'll find the following file structure:

# Exec into the running pod
kubectl exec -it my-app-pod -- /bin/sh

# List the files in the mount path
/ # ls /etc/config
database.host
feature.flags

# View the content of one of the files
/ # cat /etc/config/database.host
mysql.prod.svc.cluster.local

Each key in the ConfigMap's data field becomes a file in the mountPath directory. The filename is the key, and the file's content is the value.

3. Mounting a Secret as a Volume

The process for mounting a Secret is nearly identical, which is part of the power of Kubernetes' design patterns.

The main differences are:

• In the spec.volumes section, you use a secret block instead of a configMap block.
• It's a best practice to mount secret volumes as readOnly: true to prevent the application from accidentally modifying the sensitive files.

Following the example, if we have a secret named db-credentials, the manifest would look like this:

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod-with-secret
spec:
  containers:
  - name: my-app-container
    image: busybox
    command: [ "/bin/sh", "-c", "sleep 3600" ]
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
      readOnly: true # Best practice for secrets
  
  volumes:
  - name: secret-volume
    secret:
      secretName: db-credentials # Point to our Secret

Just like with the ConfigMap, Kubernetes handles the rest. It fetches the Secret, decodes the Base64 values, and makes them available as files in the /etc/secret directory inside the container.

spec:
  # ... other container specs
  containers:
  - name: my-container
    # ...
    volumeMounts:
    - name: token-volume
      mountPath: /etc/keys
      readOnly: true
  
  volumes:
  - name: token-volume
    secret:
      secretName: api-tokens

4. Advanced: Mounting Specific Keys

Sometimes, you don't need to mount every key from a ConfigMap or Secret. You might also want to control the exact filename for a mounted key. Kubernetes allows this using the items field within the volume definition.

This gives you fine-grained control over the files that appear in your container.

# ...
  volumes:
  - name: config-volume
    configMap:
      name: app-config
      items:
      - key: database.host       # The key from the ConfigMap
        path: db_host.txt        # The filename it will have in the volume
      - key: feature.flags
        path: features.conf

When this volume is mounted, the /etc/config directory will contain db_host.txt and features.conf instead of files named after the original keys. This is useful for integrating with legacy applications that expect configuration files with specific names.

Conclusion

Great work! You now understand how to securely and flexibly provide configuration to your applications by mounting ConfigMaps and Secrets as volumes. This method is fundamental to building robust, manageable services on Kubernetes.

Key Takeaways:

• Mounting configuration as volumes allows for dynamic updates without restarting your Pods.
• For Secrets, volume mounting is more secure as it uses an in-memory filesystem and avoids exposing credentials as environment variables.
• The process involves defining a volume that points to the ConfigMap or Secret, and a volumeMount that places it into the container's filesystem.
• The syntax for mounting Secrets is almost identical to ConfigMaps, simply replacing configMap with secret in the volume definition.
• You can mount specific keys and control filenames using the items field for more advanced use cases.

While volume mounting is powerful, especially for multi-line configurations or when dynamic reloads are needed, sometimes all you need is a simple value. In our next lesson, we will cover the second major method: injecting ConfigMap and Secret data as environment variables.