Using Passwords and Config in Kubernetes — Part II (Volume Mounts)

This is part II of using Passwords and Config in Kubernetes. Part I is available here

In the previous post , I discussed the workflow to use passwords and configs in Pods as environment variables. This will work for a large class of applications.

However, There are some applications which cannot use environment variables and expect configuration and passwords to be read from the file system.

Kubernetes provides a mechanism to pass ConfigMap and Secret into Pods as files. Some examples applications are:

• The binary cannot use environment variables
• The secret or config data should not be changed by the pods using it — Immutability
• The data in the secret or config is larger than MAX_ARG_STRLEN on your kernel. (path/to/linux/headers/include/uapi/linux/binfmts.h)
• Grouping of config data and/or Secret data is needed to make it easier to manage.
• Granular permissions on who can read/write this data is needed.

Config and Secrets as Files

Volumes with Config/Secret data can be mounted into Pods. (src)

Kubernetes Pods can access passwords and configs as Volumes. It provides two volume sources for this purpose:

1. Projected Volume Source (Secrets and ConfigMaps)
2. Secret Volume Source (Secrets only)

Declaring Config and Secrets

In order to use ConfigMap and Secret as files, they need to be declared first. Here’s an example ConfigMap and Secret, to which I’ll be referring in the subsequent sections.

config_map:
  data: 
    db_name=colors_db
    table_name=purple
  name: config_data
  version: v1
---
secret:
  data:
    username: my-username
    password: my-password
  name: secret_data
  version: v1

Note: I’ve used the cleaner and simpler Koki Short syntax to declare these resources.

Using Config and Secret as Files

Once the Secret and/or ConfigMap have been created, they can be consumed by a Pod in the same namespace.

In order to consume the Secret or ConfigMap as Volume Mounts, here’s the syntax for a pod resource that consumes it:

pod:
  labels:
    app: nginx
  name: nginx
  namespace: default
  version: v1
  containers:
  - name: nginx
    image: nginx
    volume:
    - mount: /secret
      store: secret-volume
  volumes:
    secret-volume:
      vol_type: projected
      sources:
      - secret: secret_data
        items:
          /secret_data/user-file: username:0644
          /secret_data/pass-file: password:0400

The above examples mounts a secret as a Projected volume (click for docs). Here’s an example of the same secret mounted as a Secret volume:

pod:
  labels:
    app: nginx
  name: nginx
  namespace: default
  version: v1
  containers:
  - name: nginx
    image: nginx
    volume:
    - mount: /secret
      store: secret-volume
  volumes:
    secret-volume:
      vol_type: secret
      vol_id: secret_data
      items:
        /secret_data/user-file: username:0644
        /secret_data/pass-file: password:0400

In both of the examples above, the container named nginx will have a volume mounted at path /secret with the directory structure shown below

/secret
/secret/secret_data/user-file rw-r--r--
/secret/secret_data/pass-file r--------

The nginx container can access these files at their corresponding locations.

It is important to note that the file system permissions on these files correspond to specific keys within ConfigMap or Secret. This kind of granular control over permissions can be used to make specific parts of the data immutable — i.e. If the permission is set to 0400(read only mode), then the data can only be read and immutability guarantee can be achieved.

Note that it is possible to set file permissions on all of the items at once. Please refer to the documentation for more information.

A similar operation for mounting ConfigMap is also possible. More information on the syntax for achieving this is available here. An example is provided here.

Conclusion

The syntax used above is called Short syntax, designed to be a more readable form of YAML than the machine-oriented Kubernetes API spec. We encourage everyone to use the short syntax, because

• It takes the verbosity out of view from the Kubernetes manifests
• Faster to understand the manifests, faster to write new manifests
• Completely translatable back and forth between Kubernetes and Short format
• Open Source and Free

Learn more about Short or download examples to play with. You can also try out the Chrome extension to translate live on your browser!

Have a happy new year, and stay tuned for more Kubernetes Deep Dives!