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?
Additional Context
No response
Feature Description
Bootstrapping a new kcp instance with kcp-operator is still a bit of a frustrating experience, because you can create
Kubeconfigobjects, but unless they encode a privileged group likesystem:masters, the resulting kubeconfig is unable to access kcp.We should allow bootstrapping basic
ClusterRoleBindingsinto a target workspace (mostlyroot, I suppose) for identities managed byKubeconfigsso 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
KubeconfigCRD. It could look like this:workspacePathis the target workspace (identified by colon-separated path) andclusterRolesis the list of targetClusterRolesin the workspace thatClusterRoleBindingsshould be created for.Alternative Solutions
No response
Want to contribute?
Additional Context
No response