New OCI Attestor

[ChaosInTheCRD]

What this PR does / why we need it

Description

The OCI attestor is currently able to tell us the Image ID and the Manifest Digest. If we are able to get the manifest for a container image , we can get its ID and use that as a backref. However in some scenarios (like in the case of multiarch images), or if we want to find where a particular container image is running based off of its Image ID, the Image ID is not too much help. Instead it would be great if we could use the OCI image digest.

Currently, the OCI attestor is not able to ascertain Image Digest. This is due to the fact that said digest is only established once it is pushed to the registry. However, many container build tools (docker, podman, buildah, ko) provide the ability to build and push at the same time. Therefore, we can leverage this in order to allow the OCI attestor to get the OCI image digest once it is pushed.

Without any known reliable way of getting the image digest of the most recently pushed container image from the container runtime, this means that the container build tool must have a mechanism for storing information about the build to a file. Docker offers a --metadata-file flag that saves a metadata file of the following schema:

{
  "buildx.build.provenance": {
    "buildType": "https://mobyproject.org/buildkit@v1",
    "materials": [
      {
        "uri": "pkg:docker/ubuntu@latest?platform=linux%2Farm64",
        "digest": {
          "sha256": "72297848456d5d37d1262630108ab308d3e9ec7ed1c3286a32fe09856619a782"
        }
      }
    ],
    "invocation": {
      "configSource": {},
      "parameters": {
        "frontend": "dockerfile.v0",
        "locals": [
          {
            "name": "context"
          },
          {
            "name": "dockerfile"
          }
        ]
      },
      "environment": {
        "platform": "linux/arm64"
      }
    }
  },
  "buildx.build.ref": "strange_lalande/strange_lalande0/5a8n66jm348haj9nrxny4cig8",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.oci.image.index.v1+json",
    "digest": "sha256:15f24cb4f49653d3172714ef5d1d6a949f385217ad896c46e8cf31b87efe55b1",
    "size": 856
  },
  "containerimage.digest": "sha256:15f24cb4f49653d3172714ef5d1d6a949f385217ad896c46e8cf31b87efe55b1",
  "image.name": "ghcr.io/chaosinthecrd/mic-test:testtest"
}

As you can see, the container image digest is present, along with other valuable information like id of the buildx builder (if used), the materials used (e.g., base-image) and the name of the image (given by the user for the build. Given the support of this flag, and given that docker is likely the most common container build tool, the changes in this PR primarily look for this metadata file as a product in order to populate the attestor.

One behaviour that is important to note with docker that will affect the output of the attestor is that cross-platform builds result in less metadata. You can see this here with a metadata file output from the command witness run --log-level debug --step image-build -o image-build.json -a oci --signer-file-key-path=./private_key.pem -- docker buildx build . --platform linux/amd64,linux/arm64 --metadata-file=metadata.file -t ghcr.io/chaosinthecrd/mic-test:testtest --push:

{
  "buildx.build.ref": "strange_lalande/strange_lalande0/m63k9wn3wrxnxlfsfmvylj1ag",
  "containerimage.descriptor": {
    "mediaType": "application/vnd.oci.image.index.v1+json",
    "digest": "sha256:2186da2dc06e04d084d043a82f5a22bdb95ec71c17a4e575d8534899efb3edcd",
    "size": 1609
  },
  "containerimage.digest": "sha256:2186da2dc06e04d084d043a82f5a22bdb95ec71c17a4e575d8534899efb3edcd",
  "image.name": "ghcr.io/chaosinthecrd/mic-test:testtest"
}

In this case, the materials are not present, meaning that we cannot reliable determine the base image in this case.

Of course there are also scenarios where other build tools will be used. Some build tools (e.g., podman) provide the ability to store the image digest to a file. For example, the command ./witness run --log-level debug --step image-build -o image-build.json -a oci --signer-file-key-path=./private_key.pem -- /bin/sh -c "podman build . -t ghcr.io/chaosinthecrd/mic-test:testtest && podman push ghcr.io/chaosinthecrd/mic-test:testtest --digestfile=./mictest.sha256" saves the following to mictest.sha256:

sha256:c6cc15c2219d8ed05dc600a02d08c4d5adf9e948e64cdf0e25f9e3c83616aeda

The changes in this PR support picking up products with a sha256: inside in this very manner. This also provides an easy mechanism for other build tools to add compatibility with the attestor in the future. Finally, it even leaves the door open for users to store the hash to a file in their pipelines in order to attest the creation of new container images.

[colek42]

Lets just bring this code in tree

[ChaosInTheCRD]

seems reasonable to me.

[ChaosInTheCRD]

ah shoot sorry - this code is not meant for this PR, hold on