In the story, Goldilocks complains that Papa Bear's porridge is too hot, Mama Bear's is too cold, and Baby Bear's is just right. In the next section, she finds Papa Bear's bed is too hard, Mama Bear's bed is too soft, and Baby Bear's bed is just right.

If you set the security on containers too tight, many containers will not run.

If you set the security on containers too loose, you didn't really secure them.

When I want to lock down containers, I look for the Goldilocks level, where the container can be as secure as possible. Still, most containers run within the default constraints.

Why does your container fail with "permission denied"?

Many users' only choice is to run with --privileged mode. When the container runs fine with --privileged , users need to understand what those privileges mean: They mean you are beyond Mama Bear's territory. The --privileged flag turns off all security separation on the container. The container processes get the same privilege as if they were run directly by the user. If the user is root, the processes get full root privileges.

Note: Even in --privileged mode, containers are still subject to namespace protections, including the user namespace. I will cover those later in this article.

This article explains how to figure out what the container is trying to do that is blocked by container security and how to run your container with more protection than --privileged .

Why Podman?

Because I work on Podman, most of the rest of this article covers using it to secure containers, but the concepts and separation apply to other container engines like Buildah, Docker, CRI-O, and containerd.