Managing Secrets within Container image using Podman

Test Environment

Fedora 32 installed
Podman installed

Every application that we build will have some or the other kind of secrets that we want to manage in such a way that they are not packaged into the code but are available for use when the appliation is in use. For example we might want to launch a secure httpd server instance using a container image but for secure SSL communcation we do not want to maintain the certificate and private key file within the container image. Rather we want to make those certificate and key file available to the container runtime when it is launched. The secrets can be anything like passwords, authentication tokens, certificates and private keys.

Here in this article we will see how we can manage secrets in a container image. In this article we will see how we can load secret content stored on the host machine into the container runtime instance using the podman mounts. We will see how we can actually load the secret content into the container runtime without actually storing that secret within the container image.

mounts.conf (/usr/share/containers/mounts.conf and optionally /etc/containers/mounts.conf) – The mounts.conf files specify volume mount files or directories that are automatically mounted inside containers when exe‐ cuting the buildah run or buildah build-using-dockerfile commands. Container processes can then use this content. The vol‐ ume mount content does not get committed to the final image. Usually these directories are used for passing secrets or credentials required by the package software to access remote package repositories.

If you are interested in watching the video. Here is the youtube video on the same step by step procedure outlined below.

Procedure –

Step1: Create a directory with a secret file to be managed

In this step let us create some random secret file keep it in some folder on the host filesystem as shown below.

[admin@fed32 secrets]$ pwd
/home/admin/secrets
[admin@fed32 secrets]$ cat secret.txt 
fadfjksgjdkfierjeigjrgrhdrgss

Step2: Make sure you have podman and build installed

As a prerequisite make sure you have podman installed on your system.

[admin@fed32 secrets]$ podman --version
podman version 2.2.1

Step3: Update the mounts.conf to volume mount the secret.txt automatically into the container

Let’s create the below moutns.conf file in the host system and update the content as shown below to map the host filesystem where our secret file is available to the container filesystem.

[admin@fed32 secrets]$ cat /etc/containers/mounts.conf 
/home/admin/secrets:/run/secrets

Step4: Instantiate a container and check the secret loaded into the container automatically or not

Now let’s launch a container from the busybox image and validate that the host filesystem secret file is available in the container filesystem when the container is launched.

[admin@fed32 secrets]$ podman run --name secretcontainer -it docker.io/library/busybox ls -ltr /run/secrets/ 
total 4
-rw-rw-r--    1 root     root            30 Jan 12 18:41 secret.txt

Step5: Validate the container image layer

podman unshare command, switches you into the user namespace that rootless Podman is currently running, so things look exactly the same for unshare as they do for rootless

[admin@fed32 secrets]$ podman unshare
[root@fed32 secrets]# mnt=$(podman mount secretcontainer)
[root@fed32 secrets]# ls -ltr $mnt/run/secrets/
total 0
[root@fed32 secrets]#

Note the secrets directory gets created since this is the mount point necessary for the volume, but the content is not in the container image.

Step6: Start the container and revalidate the secret

You can again start the container and attach to revalidate if you are able to see the secret.txt file available in the mount point within the container.

[admin@fed32 secrets]$ podman start -i --attach secretcontainer
total 4
-rw-rw-r--    1 root     root            30 Jan 12 18:41 secret.txt

Hope you learned something in this article. Thank you..