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:

1. What is the difference between the two mechanisms?
2. When should you use one versus the other?

I'll address these questions in this post.

How to use raw Podman secrets

The 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.

[ Get hands on with Podman in this tutorial scenario. ]

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-kube-secret into MY_PASSWORD. It then prints the value of MY_PASSWORD and exits. Since you expect the container to exit, set its restartPolicy to Never.

Execute the pod using Podman:

$ podman kube play pod.yaml

Because 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!

Wrapping up

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) ]