Question: Cross Repo References

[dlorenc]

Does the spec for the referrers API currently allow for cross-repository references? This has been a user requirement for a few organizations that want to put signatures in a separate repository from the images themselves.

This is mostly done for security and permissions: developers that can sign images may not need write access to the repository the images are stored in. Registries could solve this with fine-grained permissions, but many only implement permissions at the repository-level.

[michaelb990]

Currently, we do not.

The registry MUST return a 400 response code when subjectManifest is not found in the same repository, and not a manifest.

I have a few reasons for preferring the way it is today.

1. I personally think that finer-grained permissions would probably be cleaner here. E.g. allowing user A to push to repo A, but ONLY if the artifactType is a signature (or some similar check). Are there other examples of cross-repository descriptors? From the descriptor in the image-spec, it sounds like this could be accomplished via the urls field, but we would still want a way of restricting the locations that the subjectManifest could reside to only other repositories in the same registry so that the reference would eventually be able to be surfaced in the call to the /referrers api.
2. It seems like the lifecycle management requirements we've been discussing gives us another reason to require that reference artifacts exist within the repository of the image that they reference. I think that whether or not garbage collection guidance makes it into any OCI spec, we do not want to expand the scope that a GC process has to be concerned with to be bigger than a repository.
3. Theoretically, isn't this actually one of the scenarios that image signing makes a lot easier. If you have admissions controllers that restrict the images you run to ONLY be ones that have been signed by approved publishers, you can enforce these finer grained authorization mechanisms at runtime via signatures checks instead of relying on a registry-specific permissions scheme.

I may be missing something with these reasons though. Do you have an idea of how this would look if it were supported? Maybe that would be helpful in discussing this question.

[dlorenc]

1. I personally think that finer-grained permissions would probably be cleaner here.

Yeah definitely, I agree completely.

1. Are there other examples of cross-repository descriptors?

Cross repo blob mounting is the closest I can think of, and this case feels pretty similar actually (but in reverse kind of).

3. Theoretically, isn't this actually one of the scenarios that image signing makes a lot easier. If you have admissions controllers that restrict the images you run to ONLY be ones that have been signed by approved publishers,

It's not really about publishers, IIUC. The use case is to only allow deploying an image that two members of the team have signed using physical hardware tokens. The team members don't have permissions to push to the production repository, only the build system does.

[dlorenc]

Here's the overall architecture that was described (this came from a real end user so I'm a little shaky on the details, but overall it makes sense and there's not a ton I would change):

In cosign we solved this by allowing users to specify a separate repository for signatures to be stored and queried from in the client. This works because we can upload signatures for any image to any repository, whether it exists or not.

This is one of the worries I have with tying lifecycle into the spec here, it would preclude supporting this use case. If we removed this section and allowed clients to upload reference types for objects that don't exist, this case would still be possible:

The registry MUST return a 400 response code when subjectManifest is not found in the same repository, and not a manifest.

[michaelb990]

If I understand this correctly, it would be a few things:

1. As you mentioned, registries would need to drop the requirement that the subjectManifest be present in the repo. There also may be some additional requirements that should be relaxed, such as the following from artifact-manifest.md which I believe we talked about doing in this week's meeting when discussing Why do we define Lifecycle Management in the artifact-spec? #20 :

   A distribution instance SHOULD delete, (refCount -1) the artifact when the subject is deleted.

2. Discovery might need to change? Would registries need to track cross-repo links or could they just exist separately. If they existed separately, clients would need to be configured to look at an alternate "signature" repository. Using configuration outside of the distribution/artifacts spec to do this would be my preference, though I may be biased as a registry operator.

3. The referrers API would need to work for digests that aren't present in the repository itself. I'm not sure we've really defined this behavior well enough in the spec yet. My initial assumption had been that the referrers API would return a 4XX when the references for a digest that it doesn't recognized is requested. Seems like this would imply that it should return a (potentially empty) list even when the subjectManifest isn't part of the repository.

[jonjohnsonjr]

Seems like we want something similar to non-distributable layers, which would be a nice mechanism if we decoupled it from media types.

[SteveLasker]

Previous proposal and discussion: opencontainers/artifacts#27

[dlorenc]

Non distributable layers seem like a good fit too here, good catch @jonjohnsonjr.

[SteveLasker]

closing as cleanup for inactive discussions