feature: add supplementary group to `initializingworkspaces` impersonation

[embik]

Feature Description

Workspaces can have initializers defined, depending on the WorkspaceType that is referenced. To facilitate workspace initialisation, we have the initializingworkspaces virtual workspace (https://github.com/kcp-dev/kcp/tree/main/pkg/virtual/initializingworkspaces/). This virtual workspace is used by both built-in controllers (for default API bindings defined by the universal WorkspaceType) and potential external controllers.

The virtual workspace allows access to the "content" (i.e. to the whole workspace) of a logical cluster currently waiting for its initializer to be removed. This access is done via impersonation of the owner of the Workspace object.

It would be nice if the impersonation in question would be enriched by a group that reflects the WorkspaceType the initializer belongs to. This way it would be possible to assign permissions to a certain WorkspaceType, not individual users (since the owner of a workspace needs to be able to e.g. bind APIExports referenced in default API bindings).

The group schema could look like system:workspacetype:<workspace path>:<workspacetype name>, e.g. system:workspacetype:root:universal, but this would be up to discussion.

Proposed Solution

1. Enrich

   kcp/pkg/virtual/initializingworkspaces/builder/build.go

   Line 257 in 8e798ba

   thisCfg.Impersonate = rest.ImpersonationConfig{

   with a group as per the proposed schema above.
2. Investigate ramifications of this change! In terms of APIBindings, this would mean that Workspaces can be initialised with APIBindings that the Workspace owner couldn't create themselves. Will this create problems? What happens if the user tries to modify the APIBinding now?
3. Add an e2e test that validates the scenario: A user creates a Workspace from a certain WorkspaceType, but would not have the permission to bind an APIExport themselves. Since permissions are granted to the synthetic group, the Workspace should get an API bound successfully, but the user should not be able to create a similar APIBinding themselves.

Alternative Solutions

1. Attach a warrant to the impersonation.

Want to contribute?

• I would like to work on this issue.

Additional Context

Relevant Slack thread

[cnvergence]

I would be interested in picking up this topic 🙂