Description
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