Add support for reading image digests from a file

[mattmoor]

Description

Tools like kaniko have support for writing the published digest to a file to support results in systems like Tekton.

Signing these digests is awkward currently because you need to use shell functionality to read the result file:

    - name: sign-result
      image: gcr.io/projectsigstore/cosign:v1.4.0
      env:
      - name: COSIGN_EXPERIMENTAL
        value: "1"
      command: [/busybox/sh, -c]
      args: ["/ko-app/cosign sign $(cat /tekton/results/IMAGES)"]

I propose adding support for reading these from a file. A (straw-person) pattern for this would be to use @filename, which would shorten this to:

    - name: sign-result
      image: gcr.io/projectsigstore/cosign:v1.4.0
      env:
      - name: COSIGN_EXPERIMENTAL
        value: "1"
      args: ["sign", "@/tekton/results/IMAGES"]

[dlorenc]

Maybe this would be a good opportunity to switch to signing descriptors. @sudo-bmitch had some ideas here too. If we start signing descriptors we'll need more than just the digest (mostly size) so this file should support that too.

[sudo-bmitch]

I was leaning towards the index.json file format from the OCI Layout spec. In addition to the size, we need the media type to avoid CVE-2021-41190.

[dlorenc]

WDYT @mattmoor? index.json seems like it would work, although it can contain multiple images. But then again, cosign can also sign multiple at a time.

[mattmoor]

we need the media type to avoid CVE-2021-41190.

Really only if the manifest referenced by digest doesn't include one, which I'd wager the vast majority of images/indices (still using docker media types) do, no?

That said... Honestly I care very little about the schema of the file, so long as it aligns with what Tekton Chains would expect in such a file, so I can basically pass in the IMAGES or DESCRIPTORS or whatever the result file is.

Although as I mentally tug on this thread... We then also need every tool to start adding support for emitting / augmenting these files, so we'd also need kaniko, ko, buildpacks, ... to support adding emitted image digests to this file.

[sudo-bmitch]

we need the media type to avoid CVE-2021-41190.

Really only if the manifest referenced by digest doesn't include one, which I'd wager the vast majority of images/indices (still using docker media types) do, no?

For the vast majority of images, yes. I'm thinking of possible malicious intents. Perhaps a security check is run to validate the image before signing it (maybe not a vulnerability scan since those change over time, but some kind of static compliance check), and it only sees the image descriptor and checks that. The attacker then uses that signature to deploy the index with a malicious image to prod on a different registry.

My thought for the OCI Layout is that it makes a nice way to pass an image between steps in a CI pipeline, only pushing to the registry near the end of the pipeline when your ready to deploy, rather than the beginning while you're still validating the result. It will probably be a while before the tooling gets to that point, but I'm pushing for baby steps in that direction (while updating my own tooling for the same reasons).