Run only compliant container with PodMan and PodMan-Compose

Dennis Zimmer
Aug 8 · 4 min read

The last post covered the PodMan usage as a more secure container management (and Docker replacement) and how to use the PodMan-compose project to run multiple container at once.

This time, we want to go even further and only run container images that we authorized and even stop a podman-compose up process if some unauthorized images were to start.

To do so we use the CodeNotary vcn project, that is a blockchain-based software notarization and enables us to run a compliant container infrastructure without any complexity. Its an enhanced version of Notary, just without the complex server setup and the internal silo limitation.

We also use the podman-compose fork of CodeNotary, to enforce container authentication and block the start of unwanted container.

Installing vcn

Before you can start to authenticate local docker or podman container, you need to either build or download vcn.

Make sure you go for the latest release:

sudo cp vcn-v0.5.4-linux-amd64 /usr/local/bin/vcn
vcn help

You can learn more about how to sign up and create a CodeNotary account to notarize images here:

Notarize podman images

First lets see what images we have already pulled locally:

podman images
localhost/flamescope latest 74b2245accc6 9 days ago 108 MB latest 57d9b2fca364 2 weeks ago 513 MB 5.7 f6509bac4980 2 weeks ago 378 MB latest db8ee88ad75f 2 weeks ago 1.44 MB 3-alpine3.8 f11f279751de 3 months ago 82.6 MB latest 18f01f6f77ef 12 months ago 426 MB 3.1 da86e6ba6ca1 19 months ago 747 kB

The real important parts are the image names and image id’s as you can use them to notarize the container image. Notarizing means, that the unique fingerprint of the container image will be signed on a blockchain using your unique identity. Furthermore file metadata are added, custom metadata and the trust status given by you. Btw. other people can also authenticate these images and get your details if you notarize it public using the -p flag.

vcn sign -p --attr production=1 podman://

As you can see the container image has been notarized including my custom attributed production, that I’m going to use to allow images in my environment.

Authenticate podman image

Everyone can now authenticate the container image I signed, either against no identity (did anyone notarize it?), my identity (did I notarize it?), my organization (did anyone in my organization notarize it?) or a specific attribute like trust level, trust status and a custom attribute.

vcn v -k 0xab09fbef02de51f87df65640e6683803a3a2f01d podman://

Now I can combine a authenticate command of vcn (checking my identity and the custom attribute) with the podman command:

vcn v -k 0xab09fbef02de51f87df65640e6683803a3a2f01d podman:// -o json| jq -e '.artifact.metadata.production == "1"' && sudo podman run

or if you don’t want to repeat the image name

image=""; vcn v -k 0xab09fbef02de51f87df65640e6683803a3a2f01d podman://$image -o json| jq -e '.artifact.metadata.production == "0"' && sudo podman run $image

Of course you can create alias or a script around, so podman can never start without a vcn check before.

Installing podman-compose (CodeNotary fork)

git clone

To get a general overview how to use podman-compose please check out my other post. I also use the same docker-compose example for running wordpress in this post.

<< docker-compose.yaml >>
version: '3.3'
image: mysql:5.7
- db_data:/var/lib/mysql
restart: always
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_USER: wordpress
- db
image: wordpress:latest
- "8000:80"
restart: always
db_data: {}

Authenticate using podman-compose

No images are currently signed, so let’s run the normal podman command.

cd podman-compose./ up

You’ll notice that every time a new service starts, there is a line showing vcn authentication (verify)

vcn verify podman://mysql:5.7
Searching for the last with highest level available signature...
Error: f6509bac49801f48628167728aba66d64533aaa7d384e03b75a8fe4e6c0f6599 was not signed

Of course you can log these messages into your ElasticSearch and index it for later audits.

Enforce content trust

Much more elegant would be to use the enforce-content-trust flag, so the starting process will automatically be stopped, when one or more container images are not notarized.

./ --enforce-content-trust up

You’ll find a different output:

Error: f6509bac49801f48628167728aba66d64533aaa7d384e03b75a8fe4e6c0f6599 was not signed
CodeNotary Enforce Content Trust detected an unsigned container image and stopped the process.

There are 2 container images used, that needs to be signed under the user that should run the container:

# the container images of the docker-compose.yaml file
# pull the images locally first, under the user you want to run the containerpodman pull mysql:5.7
podman pull wordpress:latest
# notarize the container images
vcn sign -p --attr production=1 podman://mysql:5.7
vcn sign -p --attr production=1 podman://wordpress:latest

Let’s run the again:

./ --enforce-content-trust up

Follow us on Twitter 🐦 and Facebook 👥 and join our Facebook Group 💬.

To join our community Slack 🗣️ and read our weekly Faun topics 🗞️, click here⬇

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇


The Must-Read Publication for Aspiring Developers & DevOps Enthusiasts

Dennis Zimmer

Written by

Fullstack Monitoring, Analytics, Security: VMware, Docker, Kubernetes, Applications



The Must-Read Publication for Aspiring Developers & DevOps Enthusiasts

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade