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:

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?

  • Michael Altfield@slrpnk.netOPEnglish
    1·
    16 hours ago

    Open-Source Software.

    Can I install nix securely (eg with apt) to run inside the free CI runners provided by GitHub, GitLab, and Codeberg?

    • moonshine69@lemmy.nzEnglish
      1·
      11 hours ago

      Maybe not apt…but sudo dnf install nix nix-daemon

      Edit: which doesn’t answer your question about free runners… but can you trust them anyway? They are running a container afaik

      • Michael Altfield@slrpnk.netOPEnglish
        1·
        7 hours ago

        We do our pre-releases on CI runners for convenience. GitHub automatically kicks-off a build when we git push.

        When it comes time to do a real release, we can just run the job locally on our build machines (this is easier thanks to docker). Because our builds are reproducible, we can just check that the hash matches on our local build and the one from the free GitHub CI runners. That way we don’t have to trust the infrastructure, but we can use it for free & easy iteration before our final release.