Moving images/layers without imageMappings

[squillace]

Hi all. Here's the scenario. I am building bundles for a public repo like GHCR or DockerHub. When I copy them to a private registry, Porter is going to create an imageMapping that will contain references back to the originating registry layers. When going from a public to a private registry, this is fine! Those original layers can be used for verification.

It also enables some information "leakage" when going back the other direction, whether intentionally or unintentionally. Let's image that I'm saving the bundle in a private ECR. Then I porter copy the bundle to GHCR. Now I'm going to have an imageMapping section with references to layers in a private registry. Although no one can reach those layers without the proper credentials, it does expose internal paths to malicious parties who if they gain the proper access can now spelunk because they have the map to those layers.

So this first question is, how to "copy" an image but exclude the imageMapping information? This shouldn't be default, but it should be a switch that basically says, "do not rebuild the artifacts -- I want precisely those ones. But I do not wish to include this metadata along with it, as I intend to 'verify' them another way."

We could, of course, merely retag and rebuild the bundle to publish to another registry. However, the objection here is that at some level we have to then trust that the image was built in precisely the same environment and that the underlying base image did not change between building moments. If we were able to build on a baseimage tagged by digest rather than tag, then "retag" would be fine.

Am I explaining the problem? We must either a) use the same artifact in both locations but without "information leakage", or b) be able to build and retag but ensure using a digest reference that the underlying baseimage is precisely the same, not "probably" the same.

[carolynvs]

Yup! Makes sense. There are a few places where the original location of images are stored:

• porter.yaml images section (for images declared by the author as used by the bundle)
• bundle.json
  • invocation image
  • images section
• relocation mapping file

We could add a flag to porter copy, perhaps --rewrite (name TBD), flag that tells porter to update these files inside the invocation image (squashing layers to remove traces of the previous values) and bundle manifest. We may want to use that flag for publish too, in the case of publishing from an archive, e.g. porter publish --archive mybun.tgz --rewrite. That way you could archive the bundle, and restore it to another registry removing the references to the old location.

Note that there isn't a way to reuse the original invocation image without having docker modify it and create a new image with a new content digest. The values that you want to replace are inside the invocation image.

[squillace]

Right, interesting. Here's the larger problem space. IF there's no easy way to reuse invocationImages that are identical but don't expose originating information, I have a feeling that larger, for-profit registries will make an argument that you can never move images from one place to another for this reason of ultimate certainty. If that happens, it would dramatically reduce sharing of images with the confidence that it's the original built artifact.

What if we use tags and sign the image? We'd still need to prevent the insertion of originating information when requested imperatively, meaning that if you didn't request the removal you'd get it by default with the assumption of sharing and confirming.

[carolynvs]

I think that the problem with rebuilding the invocation image could be worked around by not putting any identifying information in the original invocation image and the porter.yaml and bundle.json injected at runtime. Any images used by the bundle would be parameterized to allow resolution at runtime.

The bundle itself though... I'm not sure about. Speaking only about the spec, not how cnab-to-oci works, the bundle manifest contains the bundle.json and an optional relocation mapping file. The bundle.json cannot parameterize the invocation image reference. So changing where the invocation image is located (without a relocation mapping file) requires changing the content of the bundle, which invalidates the signature.

Being able to parametrize the invocation image, and allowing that as well to be injected at runtime, isn't in the CNAB spec. So changing that would need to be a conversation at the CNAB meeting or in the spec's repo. Talking with Radu would be good since signing isn't something I'm up-to-date on, it's not even in Porter yet.

My gut reaction is that signing a bundle that doesn't reference any images, is meaningless? 🤷