feature: privileged annotations and labels for API providers



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

2022-10-04 08:14:58

Add a Comment

Top 3 Comments

  maleck13 answered on 2022-10-05 07:29:14

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. "" 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.

1 positive reactions.
  stevekuznetsov answered on 2022-10-04 16:11:30

@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?

0 positive reactions.
  sttts answered on 2022-10-04 14:57:32

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

0 positive reactions.

Repo Information

Age 1yr
Vendor kcp-dev
Repo Name kcp
Primary Language Go
Default Branch main
Last Update 15 hours ago

Similar Issues

πŸ’Ύ kcp :sparkles: Front proxy user gating πŸ’¬ 3 open πŸ—“οΈ 3 weeks ago
πŸ’Ύ kcp :seedling: test-server: split New/Start/Ready phases πŸ’¬ 8 open πŸ—“οΈ 4 weeks ago
πŸ’Ύ kcp :bug: Clean up shadow CRDs after API bindings are deleted πŸ’¬ 3 open πŸ—“οΈ 4 weeks ago
πŸ’Ύ kcp :seedling: sharded-test-server: consistently use workDirPath πŸ’¬ 3 closed πŸ—“οΈ 4 weeks ago
πŸ’Ύ kcp πŸ› Fix: watch a certain synctarget only πŸ’¬ 4 closed πŸ—“οΈ 1 month ago
πŸ’Ύ kcp :sparkles: one DNS nameserver per workspace πŸ’¬ 3 open πŸ—“οΈ 1 month ago