The most surprising thing about Podman secrets is that they aren’t a magical, encrypted vault; they’re essentially just files with restricted access, and their security relies almost entirely on the host system’s permissions and Podman’s careful handling of those files.
Let’s see this in action. Imagine you have a database password you need to pass to a container.
First, you create the secret on the Podman host:
echo "my-super-secret-db-password" | podman secret create my-db-secret
This command doesn’t encrypt the password. It creates a file in a special directory managed by Podman (typically /var/lib/containers/storage/secrets/) and sets strict file permissions on it.
Now, when you run a container that needs this secret, you mount it:
podman run -d \
--secret id=db_password,src=my-db-secret \
my-app-image
Inside the my-app-image container, the secret will be available as a file at /run/secrets/db_password.
The id=db_password part is how you name the secret inside the container. The src=my-db-secret is the name of the secret as you created it on the host.
Here’s the mental model:
- Creation:
podman secret createreads from standard input (or a file) and writes that data to a secure location on the host. It then applies file permissions (0600or0400depending on the Podman version and configuration) to this file, meaning only the root user on the host can read it. - Storage: These secret files reside in a dedicated directory managed by Podman. This directory itself is usually owned by root and has restricted access.
- Mounting: When you run a container with
--secret, Podman mounts the host’s secret file into the container’s filesystem, typically under/run/secrets/. This mount is a bind mount. - Container Access: Inside the container, the secret appears as a regular file. If the container is running as root, it can read the secret. If it’s running as a non-root user, that user can only read the secret if the container’s filesystem permissions allow it (which is usually the case for files mounted into
/run/secrets/).
The critical takeaway is that Podman’s "secret" mechanism is a convention and a set of host-level file permission controls. It prevents accidental exposure in logs or environment variables and ensures that only the intended container can access the data via a bind mount. It does not provide encryption at rest on the host unless you’ve configured your host filesystem with encryption.
If you need to manage secrets for multiple containers or want more robust encryption, you’ll likely be looking at solutions like HashiCorp Vault, which Podman can integrate with by mounting secrets directly from a Vault server using specific plugins or by having your application fetch secrets from Vault itself.
The next step is often integrating these secrets into application configuration, which involves ensuring your application code knows how to read them from the expected file path.