Exploring the new Podman secret command

We all deal with sensitive information when working with computer systems. Sysadmins move SSH keys around and web developers need to worry about API tokens. The problem with sensitive information is that it's sensitive, meaning that it could cause a security disaster if it were to somehow fall into the wrong hands. Containers are no exception to this issue—users need to utilize sensitive information inside containers while also needing to keep the sensitive information safe.

[ You might also enjoy reading: Rootless containers using Podman ]

Why secrets?

What if someone needs to run a database in a container and the credentials for the database need to be injected into a container? This can be done in multiple ways. You could simply create a file when running the container and store the credentials there. However, this is dangerous. If the container is exported into the image, the credentials would be exported as well. Anyone who has control over the image would be able to access the database. Another option is to pass on the credentials using the CLI, but that requires entering the data every single time, which can be tedious.

What if a method existed for centrally managing sensitive information?

The new command, podman secret, is a set of subcommands and options that manages sensitive information in an easy-to-use and safe way. It allows users to easily use sensitive content inside a container but keeps it from ending up somewhere outside the container, such as in an image registry. We've implemented a whole set of sub-commands for podman secret: create, rm, ls, and inspect, to create and manipulate secrets, as well as a --secret flag for injecting a secret into a container.

How is it used?

When podman secret create is run, Podman expects a file with the data to be stored.

$ echo "secretdata" > secretfile
$ podman secret create secretname secretfile
e17465c9772b38f336fc4cbac

The podman secret inspect command will not display the data stored but only metadata on the secret.

$ podman secret inspect secretname
[
    {
        "ID": "e17465c9772b38f336fc4cbac",
        "CreatedAt": "2021-02-12T09:05:49.661504248-05:00",
        "UpdatedAt": "2021-02-12T09:05:49.661504248-05:00",
        "Spec": {
            "Name": "secretname",
            "Driver": {
                "Name": "file",
                "Options": null
            }
        }
    }
]

Of course, you can also list your secrets and remove them.

$ podman secret ls
ID                         NAME        DRIVER      CREATED       UPDATED       
e17465c9772b38f336fc4cbac  secretname  file        1 second ago  1 second ago  

$ podman secret rm secretname
e17465c9772b38f336fc4cbac

In order to use the secret and access the secret data, a container can be created or run with a --secret flag. Inside the container, the secret data can be accessed inside a file at /run/secrets/secretname. You can use the --secret flag multiple times to add numerous secrets to the container.

$ podman run --secret secretname --name foo alpine cat /run/secrets/secretname
secretdata

Secrets will not be committed to an image or exported with a podman commit or a podman export command. This prevents sensitive information from accidentally being pushed to a public registry or given to the wrong person.

$ podman commit foo secrimg
Getting image source signatures
Copying blob 1119ff37d4a9 skipped: already exists  
Copying blob 3dd965b4468a done  
Copying config 263fcafb79 done  
Writing manifest to image destination
Storing signatures
263fcafb790dfdf6a7312953d3600ff9d990a664ec341ded7d0a6dfa1e71bb5d

$ podman run secrimg cat /run/secrets/mysecret
cat: can't open '/run/secrets/mysecret': No such file or directory

How does it work?

When a user uses the --secret flag, Podman retrieves the secret data and stores it on a tmpfs. It then mounts the file into the container at /run/secrets/secretname. From there, the secret can be used inside the container as usual, whether it be database keys or TLS certificates.

Secrets only exist on the secret creator's machine or inside a container when it's ready to run. Secrets are specifically designed to not exist in images: A podman commit will not commit the secret into the image, nor will a podman export. If someone were to create an image from a container with a secret, then run a container from said image, the file at /run/secret/mysecret would not exist. This prevents secret data from accidentally being pushed to a registry, thus preventing sensitive, compromising information from existing anywhere it should not be.

Future work

For now, this solution does the job of managing secrets. However, the only implemented driver at the moment to store the sensitive information is a file driver, which means that the data will be stored on disk in unencrypted files controlled by the container host. We're planning further improvements, such as implementing encryption or using other drivers. We also would like to support secret environment variables, which are environment variables that get set inside the container but are not recorded in the image. Community involvement in these tasks will be gratefully accepted.

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]

Cool. I want it.

Podman secrets is available in Podman 3.1.0. If you would like to give it a try, you can get Podman by following these installation instructions. If you already have Podman, you can get the secrets feature by upgrading to Podman 3.1.0. Feel free to reach out to the Podman team for any questions or feedback as well. Podman developers often hang out on the freenode channel #podman. You can email us by using the podman mailing list. We also have monthly community meetings. Please feel free to pop in and say hello there, too.