Accessing TUF metadata on a registry

[mnm678]

Registries are not filesystems, they are content-addressed storage. This affects artifacts and metadata in a registry will be accessed, and requires some reframing/adjustments to the TUF workflow. Some questions to answer:

• If an image is pulled by digest, how will the TUF metadata be found
• How can we set up a delegation hierarchy between repositories?

This issue is part of #2.

[sudo-bmitch]

This one has a preceding question, before we can ask how to find the metadata when pulling by digest, we probably need to start with what is TUF signing. Few ways I can think of:

1. TUF could sign a reference, that reference being an image name+tag or digest. This may be useful if Nv2 wants to delegate the tag signing to TUF, but otherwise it adds challenges with copying images.
2. TUF could sign a descriptor, same as Notary v2 is proposing, which may make it possible to swap out a layer of this for Nv2 itself.
3. TUF could use the Nv1 method of signing a tag, and the result is a digest to pull for that tag.

Unless there's a need to tightly bind things to Nv2, I see a value to keeping this modular so it's easier to reuse with any registry object. If I were to rank these, I like option 2 the best, and that descriptor could point to the Nv2 artifact, which allows us to extend Nv2 with timeliness and revocation abilities without requiring a redesign on that side to support TUF.

The downside of this is we likely lose a lot of the versioning value from TUF (knowing if we have the latest v1 image) but that might be a futile goal with registries since image tags are almost free form without a consistent way to parse everyone's versioning method, and there's a value to many users in permitting stale tags as long as they aren't revoked.

Once we sort out the above, we get to how do we find the TUF metadata, or rephrased, where is the TUF metadata stored. And there may be a line drawn here where it spans multiple places. It might be easiest to split this between what is managed by the image signer, and what will need to be managed by a separate TUF server.

I think that might mean the individual image signatures (is that the targets, and is there lots of these, one per signer, one per signature, or just one with a risk of collisions with multiple images and signers?) would be in the same repo with the images, hopefully associated to the image using the reference type. That may end up just being the Nv2 signature if we consolidate.

At that point, I suspect Nv2 would need to send an updated target notice to the TUF server, which would rebuild and update the snapshot and timestamp metadata pushed to a designated TUF metadata repo. Users could elect to consolidate these two repos into one for a single repo scenario. Assuming they don't, we'll need a pointer in each repo with signed targets with a reference to the TUF metadata repo. That might be a full reference to support organizations that span multiple registry servers, or a relative reference (something that doesn't technically exist in OCI, but wouldn't be hard to design since this is just paths on a server, and ../* isn't valid in a reference today) which would help with copying images between repositories.

With the possibility of splitting the data between repositories, we'd need a way to create that pointer in a way that can be queried. Perhaps that's just a well-known "tuf-metadata" tag that is used in every repo, and it points to either an OCI index that points to the metadata (snapshots/timestamps), or an empty index that has an annotation with the pointer, the latter being the equivalent of an http 302.

The biggest downside of splitting up this data is there's no generic way to copy an image, and all the associated signing data, between registries. The reference type won't span across repositories, so either users need to know to copy all the TUF data (using the "tuf-metadata" tags, hopefully using relative references). Also, if we get into sharding the snapshots with an OCI index pointing to nested OCI index manifests, we'll likely find tooling, maybe even registries, that we break.

I think that's enough brain-dumping for one night, but happy to brainstorm more options later.

[mnm678]

I made a diagram based on this discussion and the discussion in the meeting showing where TUF metadata could be stored using the artifact references where possible. It has the delegated targets metadata stored alongside the artifact, and a separate repository for root and top-level targets metadata. I imagine that snapshot and timestamp metadata could also be added to the TUF repository.

One thing missing from this diagram is how the client knows where the TUF repository is. The client will need to establish trust in the root keys using an external process, so it might make sense to distribute the tuf repository location at the same time?

If the artifact is moved to a new registry, the user could continue to download the TUF metadata from the original repository, or they could use a different TUF metadata repository on the new registry.

[SteveLasker]

If the artifact is moved to a new registry, the user could continue to download the TUF metadata from the original repository

This is the problematic part. The goal of content promotion is to decouple the source from the destination. Once the content is copied to the destination, which may be an air-gapped (vnet isolated) environment, by definition the client can't reach the source registry.

[sudo-bmitch]

This is the problematic part. The goal of content promotion is to decouple the source from the destination. Once the content is copied to the destination, which may be an air-gapped (vnet isolated) environment, by definition the client can't reach the source registry.

Once we transition from a single repository to multiple repositories to allow TUF to track root, snapshot, and timestamp data for an organization that has multiple repositories, the traditional image copy methods will only get us so far. Either the copy tools will need to be TUF aware, copying the metadata too. Or the users need to specify they want to copy the TUF metadata repo in addition to their requested repository.

This also assumes that pointer is to another repository on the same registry. If it points to a remote registry, you may want to leave it remote, or you may want to copy it, depending on the scenario. So I feel the pointer to the the TUF metadata should itself be unsigned data that can easily be adjusted by clients for their scenario, allowing them to copy the data and restructure the repositories, without being the signer themselves.