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