Storing sensitive data using Podman secrets: Which method should you use?
While writing Deploying a multi-container application using Podman and Quadlet, I was asked about the differences between creating raw Podman secrets and creating Kubernetes secrets using Podman. So, instead of overloading the Quadlet post, I decided to write this one.
[ Download now: Podman basics cheat sheet ]
Podman introduced secrets with version 3.1.0. Podman 4.3.0 added support for Kubernetes secrets on top of Podman secrets using the
podman kube play command.
Having two ways to achieve a similar goal raises two questions:
- What is the difference between the two mechanisms?
- When should you use one versus the other?
I'll address these questions in this post.
How to use raw Podman secrets
podman secret create command stores its entire input as one value that may be used as it is inside a container.
For example, you can store a password in a Podman secret like this:
$ printf "Gr8P@ssword!" | podman secret create my-password -
Then you can use it in your container as an environment variable:
$ podman run --secret=my-password,type=env,target=MY_PASSWORD \ registry.access.redhat.com/ubi9:latest \ printenv MY_PASSWORD Gr8P@ssword!
You can read more about Podman secrets in Ashley Cui's article Exploring the new Podman secret command.
How to create a Podman secret based on a Kubernetes secret
Creating secrets using
podman kube play stores the entire Kubernetes YAML file as a Podman secret, allowing you to use it in other Kubernetes YAML files.
For example, assuming you have this Kubernetes secret in a YAML file:
apiVersion: v1 data: password: R3I4UEBzc3dvcmQh kind: Secret metadata: creationTimestamp: null name: my-kube-password
Store it as a Podman secret using this command:
$ podman kube play secret.yml
However, if you use it as a standard Podman secret in a
podman run command, the value of the environment variable is the entire Kubernetes YAML file:
$ podman run --secret=my-kube-password,type=env,target=MY_PASSWORD \ registry.access.redhat.com/ubi9:latest \ printenv MY_PASSWORD apiVersion: v1 data: password: R3I4UEBzc3dvcmQh kind: Secret metadata: creationTimestamp: null name: my-kube-password
Note that the value of
password is Base64 encoded:
$ echo $(echo R3I4UEBzc3dvcmQh | base64 --decode) Gr8P@ssword!
Instead, use the secret in another Kubernetes YAML file:
apiVersion: v1 kind: Pod metadata: name: kube-secret-print spec: restartPolicy: Never containers: - name: alpine image: docker.io/library/alpine:latest env: - name: MY_PASSWORD valueFrom: secretKeyRef: name: my-kube-password key: password command: - printenv args: - MY_PASSWORD
This pod stores the value of the key
password from the secret
MY_PASSWORD. It then prints the value of
MY_PASSWORD and exits. Since you expect the container to exit, set its
Execute the pod using Podman:
$ podman kube play pod.yaml
podman kube play runs in detached mode, you need to get the logs in a separate command:
$ podman logs kube-secret-print-alpine Gr8P@ssword!
Podman supports two ways for storing sensitive data using Podman secrets. The intention is to use each with different consumers. Therefore, whenever you need to consume the same information in two different kinds of containers, you need to create two secrets.
To consume the data in a container created by
podman run or via a Quadlet
.container file, use
podman secret create.
To consume the data in a pod created by
podman kube play or via a Quadlet
.kube file, use
podman kube play to create the secret.
[ Learning path: Getting started with Red Hat OpenShift Service on AWS (ROSA) ]