Skip to main content

Using sensitive data in containers

New Podman secrets features allow users to fine-tune their secrets settings to their liking.
Securing SNMP

"Security By Thy Name" by cogdogblog is licensed under CC BY 2.0

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

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

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
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
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.

Topics:   Containers   Podman   Events  
Author’s photo

Ashley Cui

Ashley Cui is a software engineer at Red Hat, working on Podman, Buildah, and other container tools. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.