Skip to main content

Storing sensitive data using Podman secrets: Which method should you use?

Podman supports two ways for storing sensitive data: using raw Podman secrets or creating Kubernetes secrets using Podman.
Two packages with red ribbon on red background

Photo by from Pexels

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 \ \
    printenv MY_PASSWORD


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
  password: R3I4UEBzc3dvcmQh
kind: Secret
  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 \ \
    printenv MY_PASSWORD

apiVersion: v1
  password: R3I4UEBzc3dvcmQh
kind: Secret
  creationTimestamp: null
  name: my-kube-password

Note that the value of password is Base64 encoded:

$ echo $(echo R3I4UEBzc3dvcmQh | base64 --decode)


Instead, use the secret in another Kubernetes YAML file:

apiVersion: v1
kind: Pod
  name: kube-secret-print
  restartPolicy: Never
  - name: alpine
    - name: MY_PASSWORD
          name: my-kube-password
          key: password
    - printenv

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


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)

Topics:   Podman   Security  
Author’s photo

Ygal Blum

Ygal Blum is a Principal Software Engineer who is also an experienced manager and tech lead. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.