image: expose in-toto attestation statements via the API#52636
image: expose in-toto attestation statements via the API#52636smerkviladze wants to merge 1 commit into
Conversation
github-actions
Bot
added
impact/changelog
area/images
describing how the image was built or what software it contains.
Previously the API reported that an attestation manifest exists but
discarded the statement payloads. This meant tools had to make
additional registry round-trips to read what was actually attested.
- Add Statements []json.RawMessage to AttestationProperties,
populated from in-toto statement blobs in the attestation manifest layers
- Expose via GET /images/{name} and GET /images/json when manifests=true
- Layers without an in-toto.io/predicate-type annotation are skipped;
blob read failures are logged at debug level and skipped
- Bump MaxAPIVersion to 1.55
This allows tools - audit pipelines, image scanners - to read
attestation content directly from the daemon and make policy
decisions based on what the image actually attests to, making it
also useful for examining attestations of images in airgapped
environments without access to the source registry.
Signed-off-by: Sopho Merkviladze <smerkviladze@mirantis.com>
smerkviladze
force-pushed
the
add-attestation-statements
branch
from
dce3aca to
e394bdd
Compare
corhere
added
the
kind/enhancement
| // this attestation manifest, in the order they appear in the manifest | ||
| // layers. Each element is a complete in-toto Statement JSON object. | ||
| // Only populated when manifests are requested. | ||
| Statements []json.RawMessage `json:"Statements,omitempty"` |
There was a problem hiding this comment.
We probably shouldn't expose the full content here. Perhaps only digests of these and then make the client fetch them through the c8d content store via gRPC?
There was a problem hiding this comment.
FYI, /var/lib/docker.sock supports gRPC and exposes read-only containerd content store there
|
Our ultimate goal is to evaluate policies during the container lifecycle with the same information as is available to Buildkit build policies. Buildkit does the heavy lifting of finding all the relevant attestations for the image and sending them to the builder: Since it's looking like an Engine API change would be needed regardless of which approach we take, I propose we add a new endpoint (strawman: |
3 participants
- What I did
Added
Statements []json.RawMessagetoAttestationPropertiesso that the verbatim in-toto statement payloads attached to an image's attestation manifest are returned byGET /images/{name}andGET /images/jsonwhenmanifests=true.Previously the API reported that an attestation manifest exists but discarded the statement payloads. This meant tools had to make additional registry round-trips to read what was actually attested.
- How I did it
In
multiPlatformSummary, when an attestation manifest is detected, the manifest layers are iterated and any layer annotated within-toto.io/predicate-typehas its blob read and appended verbatim toAttestationData.Statements. Layers without the annotation are skipped. Blob read failures are logged at debug level and skipped.- How to verify it
Pull an image built with BuildKit attestations and query the API directly. The statements array should contain the raw in-toto JSON objects for the locally available platform.
- Human readable description for the release notes