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
$ 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:
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
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? ]
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.