Idea: Base image validation

[dlorenc]

Using the proposed annotations: opencontainers/image-spec#821

We could identify the base image seam. We can't trust this annotation, but we can use it as a hint. We can do the following:

• Fetch the actual base image by combining the digest and location annotations. Basically, strip the tag from the org.opencontainers.image.base.ref.name and add the digest from org.opencontainers.image.base.digest.
• Compare the layers from the base image with the layers from the image, pre-seam. They should match exactly.

From there, we can fetch signatures on the base image and verify those against keys/identities.

[dlorenc]

@imjasonh @jonjohnsonjr does my annotation-munging scheme make sense?

[dlorenc]

We could do this in cosign and/or copasetic.

In copasetic it would look something like oci.base_image_ref and oci.base_image_digest just for the raw annotation values, and oci.verified_base_image_ref for fully-qualified ref of the base image (by digest), after verifying the layers.

In cosign, it could look something like cosign verify-base or cosign verify --base, and then everything else would be the same.

[Dentrax]

This morning, @developer-guy sent me a link about the OCI Base Image Annotations. And just want to look around to see if there is an active discussion issue about this.

---

What would the cosign's behavior in case there are multiple base images? Let's assume we have the following minimal Dockerfile:

# base image 1
FROM foo:v1 as foo
# base image 2
FROM bar:v1 as bar
# base image 3
FROM baz:v1 as baz

WORKDIR /src

# Create a group and user
RUN addgroup -S qux && adduser -S qux -G qux
RUN chown -R qux:qux /src

USER qux

COPY --chown=qux:qux --from=foo /usr/bin/foo /usr/bin/foo
COPY --chown=qux:qux --from=bar /usr/bin/bar /usr/bin/bar
COPY --chown=qux:qux --from=baz /usr/bin/baz /usr/bin/baz

Sorry, I'm a bit confused here, maybe I'm missing some point about the spec. Actually, is there one base image, which is FROM foo:v1 as foo?

[imjasonh]

What would the cosign's behavior in case there are multiple base images? Let's assume we have the following minimal Dockerfile:
Sorry, I'm a bit confused here, maybe I'm missing some point about the spec. Actually, is there one base image, which is FROM foo:v1 as foo?

From the perspective of the annotation, there can only be one base image -- that is, the image sharing its layers with the lowest layers of final produced image. In your example Dockerfile, there's a missing line, which is something like FROM alpine, where the files COPY --from=baz are copied into, to produce the final image. In that case the annotation would point to alpine as your base image because it shares the lowest layers. If you did FROM scratch then there would be no base.

We discussed quite a bit in opencontainers/image-spec#822 options for signalling all of these images that might have been involved in the building of the image, but ultimately decided to only report the single base image (sharing layers) because it was simpler, and because multi-stage dockerfile buildss are the only real mechanism in use today for involving multiple images in the production of another image. If anybody is interested in adding annotations for these other helper images, I think there was a general interest, but there's some complexity there we would need to account for.

I tried to describe this concisely in https://github.com/ImJasonH/ImJasonH/tree/main/articles/oci-base-image-annotations#what-about-images-used-in-multi-stage-dockerfile-builds but I'm definitely open to ideas about how to make this clearer.

[jonjohnsonjr]

What would the cosign's behavior in case there are multiple base images?

I tried to get support for multiple bases in the proposal, but everybody seemed to hate it, so I gave up.

For my own purposes, I'd also love to be able to express this kind of thing, but I don't think the world is ready for it quite yet. In the meantime, I'm planning just produce a synthetic base index that includes every image you pulled FROM. This would essentially be a snapshot of all your build dependencies at some point in time.

Assuming you have some infrastructure that could update a base index whenever any of its children update, you could use the same mechanism to detect out of date images. For example:

{
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 7143,
      "digest": "sha256:123...",
      "annotations": {
        "org.opencontainers.image.base.digest": "sha256:123...",
        "org.opencontainers.image.base.name": "deps.example.com/foo:v1"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 7143,
      "digest": "sha256:456...",
      "annotations": {
        "org.opencontainers.image.base.digest": "sha256:456...",
        "org.opencontainers.image.base.name": "deps.example.com/bar:v1"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 7682,
      "digest": "sha256:789...",
      "annotations": {
        "org.opencontainers.image.base.digest": "sha256:789...",
        "org.opencontainers.image.base.name": "deps.example.com/baz:v1"
      }
    }
  ],
}

And maintaining some infrastructure that updates this index whenever any of its children get updated. It's a bit of an abuse of this annotation, but I think it's in the same spirit as the intended use case. I might also just have my own annotation for this thing... who knows.

In general, I want to maintain metadata of the build-time dependency graph between images, and if I have to produce some synthetic placeholder nodes to make that all come together, so be it.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.