Better support for container images with OCI and/or Product Attestor

[jmeth]

The OCI attestation currently only works for .tar files output from a docker save command. In a common workflow we first build our images with docker build and the image is create typically in /var/lib/docker filesystem and visible in the docker images command output. It doesn't seem like there is currently a way to easily link the product of docker build to the input of docker save for policy enforcement. I'm not sure how this would work since docker build doesn't produce any files but maybe just tracking the tag and hash of an image as a product?

[colek42]

There are a few ways to handle this.

1. Use buildkit and output options. ref: https://docs.docker.com/engine/reference/commandline/build/#custom-build-outputs.

While testing this, I am running into an issue where the tar file just keeps getting bigger.

2. We can add support for the --iidfile flag. This writes the containerID to a file that we can use for generating the OCI attestation. This method will probably have better overall support.

[jmeth]

Yeah it seems like option 2 is probably the easiest and most straight forward. For now I've been using iidfile as a poor man's product so I can at least verify inputs/outputs between stages but it would be nice if the OCI attestor would pick up that iidfile and give me all the nice OCI data goodness in my attestation.

[colek42]

2 is going to be the way forward. Give me a couple of weeks, and we will get this working.

[colek42]

I'm thinking the most straightforward way to handle this is to look for a output file which contents match sha256:a46e07e964a1f3cfbf8d07e32f9b6f9cb51cee66538bd328ababe9bf843adac0 run a docker image inspect on that identifier

• Do we need to inspect the attestation context to check if the docker command was run with the --iidfile flag?
• Should we package the image and manually calculate the digest sets like we currently do?

@mikhailswift