Container authentication?

[shotgunwilly]

I assume, like most container runtimes, the integrity of the container image is verified before executing the image and creating the actual container? Again, assuming that images are cached locally like Docker does, is the integrity checked prior to executing local images or prior to restarting existing containers? As containers move out to the edge, it's becoming more and more important to add the security threat model of physical tampering, so always verifying image integrity, as well as existing containers, prior to executing is becoming more important. Thanks

[rhatdan]

The images are only verified at pull time, they do not handle verification at runtime.

[mattdibi]

@rhatdan resuming this old discussion since I'm interested in the topic. Is your answer applicable for Podman-only, I assume, since Docker seems to be enforcing container signature also when issuing run command, see Client enforcement with Docker Content Trust.

Is there any plan to support the same behaviour in Podman?

[rhatdan]

We plan on using composefs to ensure that signed images are never modified on the host system, if that is what you are interested in?

[mattdibi]

We're interested in preventing the user to be able tu run images that are not signed. If I understand this correctly Podman only verifies the signature when pulling the images from registry but a user could still run an unsigned container image that has been loaded on the system via other means. We'd like to prevent that (and that's what Docker seems to accomplish).

[rhatdan]

Well I think you are on a false mission, a user can run any executable that they manage to get onto the system whether through a container engine or otherwise. In the case of Docker, they are running as root, so it is potentially far more dangerous. With Podman we are giving them no more access then he gets without using a container engine. So they can download content from the internet and execute it as their UID. Not privileged.

Trying to prevent running bad content is a good idea, but at a certain point you have to trust your users or prevent your users from getting to the internet.

[mattdibi]

I get that this behaviour is not supported nor planned for the near future then... thanks for the explanation 🙏

[TomSweeneyRedHat]

@shotgunwilly I'm not sure which command you're talking about, but if you do --pull-always with a build command it always pulls the image from the registry and fails if it's not found there. It does save it to the local storage when done though, so I don't know if that's an issue or not for your scenario.

[shotgunwilly]

I'm looking at a Kubernetes environment.

[TomSweeneyRedHat]

Also, @shotgunwilly, if you have an image stored locally that has been secured, you can assure that you won't pull from a registry by using the --pull-never option which will only use the image found on local storage and will fail if not present.

[shotgunwilly]

I was actually looking for the opposite. Always pull in case local image has been modified. This is for an edge use case, so both physical access and container escapes with privilege escalation threats. I can mitigate physical access with FDE, but zero-day container escapes are tougher. SELinux, AppArmor, and seccomp are great, but I'd also like to periodically (on reboot) check image/container integrity.

[rhatdan]

You could clear the image store in that case, but you still would have to trust your Base OS including podman and it's dependencies.

[shotgunwilly]

Yeah, I think that might be the best option. We have secure boot up through verifying the OS, so we're good there. We can probably use a filesystem like btrfs, and just roll back each boot--removing any mods.