Feature Description

Bootstrapping a new kcp instance with kcp-operator is still a bit of a frustrating experience, because you can create Kubeconfig objects, but unless they encode a privileged group like system:masters, the resulting kubeconfig is unable to access kcp.

We should allow bootstrapping basic ClusterRoleBindings into a target workspace (mostly root, I suppose) for identities managed by Kubeconfigs so that you can gain access to the kcp instance and go from there (e.g. wire it up to a git repository holding all your authZ configuration).

Proposed Solution

Extend the Kubeconfig CRD. It could look like this:

spec:
  authorization:
    clusterRoleBindings:
      workspacePath: "root"
      clusterRoles:
        - "cluster-admin"

workspacePath is the target workspace (identified by colon-separated path) and clusterRoles is the list of target ClusterRoles in the workspace that ClusterRoleBindings should be created for.

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response