What do others use for ensuring the authenticity of images after downloading them with docker pull?

We’ve setup our CI build process to use docker for consistent, cross-platform builds. To ensure that our builds don’t use a malicious docker image (because the surface area of attack with TLS is enormous if you’re using X.509), we’ve been using DCT (Docker Content Trust).

Unfortunately, I just discovered that the official docker documentation says that DCT is being deprecated. Apparently this was announced last year, and in June this blog post was published with advice:

• https://www.docker.com/blog/docker-content-trust-retirement-and-migration-guidance/

Cosign is not secure

We spent some time looking into cosign, but we discovered that the private keys aren't actually in the hands of the developer.

Rather, they use this complicated setup using very insecure X.509 to issue temporary certificates.

The result is that the OIDC identity provider (e.g., GitHub) extends the vector of attack significantly -- to probably tens of thousands of people -- that can publish a malicious image that will be accepted by cosign as "trusted"

Notation (Notary v2)

I also looked at Notation (aka “Notary v2”), but there’s no way to bootstrap the software safely, since (perplexingly) their tool for verifying the authenticity of images using cryptographic signatures itself can’t be verified using a cryptographic signature.

Alternatives

Are there any other alternatives that I can use to replace DCT to ensure the authenticity (using cryptography) of the container images that I download -- where the keys are actually held by the developer (thus significantly reducing the "insider threat" risk)?

What do you (or does your org do) to ensure that you’re not using maliciously-modified containers after pulling a new docker image?

cross-posted from: https://lemmy.bestiver.se/post/742990

Comments

Source code at https://github.com/lxc/incus-os

I couldn't find a definitive answer, so I'm asking here: How do you pronounce the container runtime runc? As in trunk or as run c (run see)? Or another way I'm overlooking?

I recently migrated my services from rootful docker to rootless podman quadlets. It went smoothly, since nothing I use actually needs to be rootful. Well, except for caddy. It needs to be able to attach to privileged ports 80 and 443.

My current way to bypass it is using HAProxy running as root and forwarding connections using proxy protocol. (Tried to use firewalld but that makes the client IP opaque to caddy.) But that adds an extra layer, which means extra latency. It's perfectly usable, but I'd like to get rid of it, if possible.

I'm willing to run caddy in rootful podman if needed. But from what I understand, that means I can't have it in the same rootless network as my other containers. I really don't wanna open most of my containers' ports, so that's not an option.

So, I'm asking whether any of these three things are possible.

1. Use firewalld to forward ports to caddy without obscuring the client's IP.
2. Make rootful caddy share a network with other rootless containers.
3. Assign privileged ports to caddy somehow, in rootless mode. (I know there's a way to make all these ports unprivileged, but is it possible to only assign these 2 ports as unprivileged?)

Or maybe there's a fourth way that I'm missing. I feel like this is a common enough setup, that there must be a way to do it. Any pointers are appreciated, thanks.

Cross-posted from "Dedicated service user or not ?" by @mat@jlai.lu in !selfhosted@lemmy.world

Hi all !

As of today, I am running my services with rootless podman pods and containers. Each functional stack gets its dedicated user (user cloud runs a pod with nextcloud-fpm, nginx, postgresql...) with user mapping. Now, my thought were that if an attack can escape a container, it should be contained to a specific user.

Is it really meaningful ? With service users' home setup in /var/lib, it makes a lot of small stuff annoying and I wonder if the current setup is really worth it ?