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.
About the author
Ashley Cui is a software engineer at Red Hat, working on Podman, Buildah, and other container tools.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit