docs: Provide documentation with examples on implementing OIDC RBAC

[mjudeikis]

Feature Description

Imagine a situation:

• Single kcp instance with OIDC provider connected to it.
• Many vendors/companies use the same instance with their own UI/CLI tooling.

I want to be able to do a few things:
Based on user attributes (group or scope) in jwt token from oidc provider to grant access to APIExports. Potentially with configurable behaviour like "FilterOut" or "Deny", where multiple could be provided.

Bonus: kcp could expose possible "scopes" as a separate API (similar as .well-known file in oidc)

Proposed Solution

1. Extend kcp to be jwt attributes aware
2. Add scoping (potentially to warrants machinery)

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response

[mjudeikis]

After quick digging via: https://kubernetes.io/docs/reference/access-authn-authz/authentication/

So one could already set groups attributed based on claims in the token:

  groups:
      # Same as --oidc-groups-claim. Mutually exclusive with groups.expression.
      claim: "sub"
      # Same as --oidc-groups-prefix. Mutually exclusive with groups.expression.
      # if groups.claim is set, groups.prefix is required.
      # Explicitly set it to "" if no prefix is desired.
      prefix: ""
      # Mutually exclusive with groups.claim and groups.prefix.
      # expression is a CEL expression that evaluates to a string or a list of strings.
      expression: 'claims.roles.split(",")'
    # uid represents an option for the uid attribute.

Meaning some OIDC configured claims would land as k8s groups.

and access could be granted based on them:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-impersonator
rules:
# Can impersonate the user "jane.doe@example.com"
- apiGroups: [""]
  resources: ["users"]
  verbs: ["impersonate"]
  resourceNames: ["jane.doe@example.com"]

# Can impersonate the groups "developers" and "admins"
- apiGroups: [""]
  resources: ["groups"]
  verbs: ["impersonate"]
  resourceNames: ["developers","admins"]

# Can impersonate the extras field "scopes" with the values "view" and "development"
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes"]
  verbs: ["impersonate"]
  resourceNames: ["view", "development"]

# Can impersonate the uid "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"
- apiGroups: ["authentication.k8s.io"]
  resources: ["uids"]
  verbs: ["impersonate"]
  resourceNames: ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"]

This means that user could request claims like:
admin -> cluster admin rolebinding
mangodb -> some limited rolebinding
todo

And based on claims certain rbac rules would apply.
One could generated static rbac rules in each workspace, based on services, bound to that workspace.

[mjudeikis]

All this needs testing and proving still

[ntnn]

/retitle docs: Provide documentation with examples on implementing OIDC RBAC
/remove-kind feature
/kind documentation

[ntnn]

Done: https://docs.kcp.io/contrib/examples/oidc/readme/