feature: add logical cluster pseudo groups to cross-workspace authorization checks

[embik]

Feature Description

When doing cross-workspace authorization (SubjectAccessReviews, most often), e.g. when checking for the bind verb on an APIExport while creating an APIBinding, it would be nice to be able to assign permissions on a per-workspace basis (i.e. I want to allow access not based on individuals, but where they are trying to bind my API).

As such, I would like to be able to give permissions to groups like system:cluster:xadasdwerawf instead of individuals.

Proposed Solution

This check is happening e.g. in the apibinding admission plugin, where there is an authorizer called to check if the bind verb exists. We should be able to inject a group into the user info for that particular authorization check.

Given this, APIExport providers should simply be able to assign permissions to groups named after the schema of system:cluster:xadasdweda.

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

When implementing this, make sure to consider the ramifications of such special groups. Can someone in control of the OIDC server inject those groups into JWT tokens? Should we maybe reject JWT tokens that decode to include groups with the system: prefix (if we don't do that already, that is)?

[ntnn]

Blocking until #3481 is done to make sure the cross-workspace auth will also work for oidc users.