Including image signatures in airgap bundles

Packaging an application
, ,
1

@Evans_Mungai and I were chatting with a team that’s evaluating Replicated today and I was explaining how I include image signatures in airgap bundles using additionalImages. He mentioned he’d never seen my approach before so I thought I’d share it here.

A few months back I was working with a Replicated customer with two requirements that I hadn’t considered together before: signed images (enforced by Kyverno) and airgap installs. I was wondering how I’d solve this because I wasn’t even sure the signature would still be valid once I loaded the image into the new registry. It turns out that wasn’t a problem, the signature is valid since the image contents are the same.

Now I have very useful bits of knowledge:

  1. I just need the existing image and signature inside the airgap
  2. I can derive the signature image name/tag based on the image name/tag. The signature for the image ghcr.io/crdant/slackernews/slackernews-web@sha256:ca67a4464684c674f713b08055081ef99b8af92fef5a2de56da18dd3f612ecec is at ghcr.io/crdant/slackernews/slackernews-web:sha256-ca67a4464684c674f713b08055081ef99b8af92fef5a2de56da18dd3f612ecec.sig.

This left me with a fairly standard situation for Replicated airgap builds. I have an image (the signature) that isn’t referenced by my manifests but needs to be in the airgap bundle. That’s a known scenario with a known solution: additionalImages in my Replicated Application object.

Sure enough, when I set additionalImages with my signatures:

  additionalImages:
    - ghcr.io/crdant/slackernews/slackernews-web:sha256-22ea80c3b2e000a28f19ac8b0e3b2669131bbfb72240bd293770df27fe52bd9e.sig
    - ghcr.io/crdant/slackernews/slackernews-nginx:sha256-6add0dbeaf9718b84cb97db88d37a4815481b34bde657076846c5c1e75aeb619.sig

I get an airgap bundle with the images and their signatures in it. The images land in the registry, the policy finds them, and my application runs as expected.