Using sensitive data in containers

Developers and sysadmins often need to use sensitive data, such as API tokens or login credentials to a database. When containerizing applications, this data needs to be passed into the container without the risk of exposure outside the container, such as in an image registry. Podman has a feature—secrets—that allows users to centrally manage sensitive information and to easily and securely access confidential data inside a container. This feature prevents the secret from being exported when creating an image from a container.

Recently, Podman's secrets feature was extended to support even more features, such as user ID (UID), group ID (GID), Mode options, and environment variable secrets. These options allow users to fine-tune their secrets settings to their liking, whether it be restricting permissions or exposing the secret via an environment variable as opposed to a file.

$ podman run --secret source=mysecret,type=mount,uid=1000,gid=1001,mode=777 --name foo alpine ls -ln /run/secrets/mysecret
-rwxrwxrwx    1 1000     1001             6 Oct  4 20:04 /run/secrets/mysecret

$ export VAR=abc

$ podman secret create --env VARSECRET VAR
4a513fdd05f817f1da2fc7c66

$ podman run --secret source=VARSECRET,type=env alpine printenv VARSECRET
abc

In addition to secrets in Podman, Buildah now has secrets support as well. Buildah secrets are a little different and are used for a different case. Primarily, Buildah secrets are useful for exposing information that needs to be used in a specific RUN stage in a build but not in the final image. A Containerfile that uses this feature would look something like this:

FROM alpine
RUN --mount=type=secret,id=mysecret,target=mysecret cat /mysecret
RUN cat /mysecret

And assuming you have a file called mysecret that contains "SOMESECRETDATA," you can build the Containerfile:

$ buildah bud --secret id=mysecret,src=./mysecret .

STEP 1/3: FROM alpine
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob a0d0a0d46f8b done  
Copying config 14119a10ab done  
Writing manifest to image destination
Storing signatures
STEP 2/3: RUN --mount=type=secret,id=mysecret,target=mysecret cat /mysecret
SOMESECRETDATA
STEP 3/3: RUN cat /mysecret
cat: can't open '/mysecret': No such file or directory
error building at STEP "RUN cat /mysecret": error while running runtime: exit status 1

The first RUN command, with the --mount type=secret, can read the secret, but other commands (such as the second RUN) are not able to, nor does the secret end up in the final image. There are plenty of uses for this, but a good example would be if the build needs content that requires credentials to access. The credentials would exist only for the RUN; after the materials are pulled down and used in the build, the credentials would not persist for the rest of the build or be baked into the final image.

[ You might also be interested in reading Why can't I use sudo with rootless Podman? ]

We presented a more detailed explanation of secrets in Podman and Buildah, including some demos, at DevConf 2021. You can watch the full presentation.

DevConf is a free, Red Hat-sponsored technology conference for community projects and professional contributors to free and open source technologies. Check out the conference schedule to find other presentations that interest you, and access the YouTube playlist to watch them on demand.