APIExport RBAC for clients

[astefanutti]

Now that controllers should configure their API clients using the corresponding APIExport virtual workspace server URLs, these raises the following questions w.r.t. authorization:

1. The controller is supposed to retrieve the APIExport virtual workspace server URL, by getting the APIExport resource and read its status. While this may be fine for APIExports owned by the controller, generally the controller SA is not granted the permission to get APIExport resources in other workspaces. Similarly, it is generally not granted the permission to get APIExport resources from compute service workspaces, when consuming APIs negotiated via workload clusters. As a work-around, such a controller has to build the APIExport virtual workspace server URL manually, which seems brittle.

2. The controller client must be privileged to query the APIExport virtual workspace API server across multiple workspaces. Currently, a dedicated ServiceAccount has to be created, with the proper ClusterRole bound, but that's actually limited to one workspace, and kind of defeats the TMC feature, when it comes to deploying such a controller via kcp.

Describe the solution you'd like

Ideally, the controller SA could be granted the permissions to get the URLs of the APIExports it consumes, and access their underlying content, via standard RBAC. By an "APIExport underlying content", we mean the resources of the APIs exported by that particular APIExport, in all the workspaces that have it bound.

[astefanutti]

After some discussions, here are the actions I can see:

• For 1) / compute service APIExport: A solution has to be devised, possibly with a local APIExport claiming resources from the compute service workspace APIExport
• For 2): Document the solution to use a ClusterRole with the following rule:

- apiGroups:
   - apis.kcp.dev
   resources:
   - apiexports/content
   verbs:
   - '*'

• For 2): Adding support for create, delete and deletecollection operations in the virtual workspace API server, so it's not limited to read-only operations (see Virtual workspace server panics on create operations #1253).

[astefanutti]

The main tasks have been delivered as part of the 0.6.0 release:

• For 1) Compute service APIExport: fixed with Adding permissions claims API for granting more resource for VirtualWorkspace #1244 as part of Epic: API Export Permissions on Binding #1219.
• For 2): Adding support for create, delete and deletecollection operations in the virtual workspace API server, so it's not limited to read-only operations (see Virtual workspace server panics on create operations #1253).

Let me close this.

[astefanutti]

Documentation should be addressed in #1859.