feature: privileged annotations and labels for API providers

[maleck13]

Feature Description

Priority Low APIExports allow us to express permissions over exported API resources, however it can be the case that the provider of the API also leverages labels and annotations as part of providing the API and places those on the claimed objects. It would be useful to be able to declare a set of annotations and labels that may be applied to a resource claimed via the permission claim that cannot be modified by the end user while the APIBinding is in place.

One concern with this is ensuring it is a scalable solution.

Proposed Solution

As part of an APIExport, I declare a set of annotations/labels that I am going to use on claimed resources that an end user cannot modify (may want to allow deletion but nothing else).

Alternative Solutions

No response

Want to contribute?

• [ ] I would like to work on this issue.

Additional Context

No response

[sttts]

this reminds me of the upstream discussion about finegrained metadata field permissions, e.g. to add finalizers. cc @s-urbaniak

[stevekuznetsov]

@maleck13 is it important to allow users to mutate the rest of these objects, but not some particular annotation? Can a more coarse-grained implementation where the provider (and only the provider) is able to mutate any part of the object suffice?

[maleck13]

It is important users can mutate the rest of the object. The best example I have actually comes from KCP. There are several currently experimental annotations used by the syncer when supporting TMC that reflect status and a transformed spec. "experimental.spec-diff.workload.kcp.dev/" etc this should be tightly controlled and I believe they will be, but it is likely that API Providers will also have important annotations they they want to use to "enhance" an existing API such as ingress etc but want some of these values to be protected and only settable by the controller providing the API.