WIP - Kubeconfig RBAC

[xrstf]

Summary

This PR implements a new feature for the operator: It can now provision RBAC inside kcp and thereby grant people permissions and take them away, too.

This is now the first PR to make use of the internal-proxy (#87): since admins can configure any random workspace path or cluster name, the operator needs to be able to provision on any shard and more importantly, figure out which shard. To solve this, we use our internal proxy ("internal" still means a standalone Deployment, of course).

Each Kubeconfig object can now hold a workspace and a desired list of permissions inside that workspace. The operator will try to reconcile these RBAC resources accordingly, and also take care of cleaning up when a Kubeconfig is removed or changed (it's possible for users to change the workspace that RBAC should be placed in, and the operator will first cleanup the old cluster and then provision the new one).

To keep track of where RBAC has been deployed, a new field in the Kubeconfig status has been introduced. We discussed this and decided that this is a safe place to do so, as anyone with permissions to manage Kubeconfigs is technically an admin and so endusers cannot/should not fiddle with Kubeconfigs. If that were possible, the operator currently has no way of defending against malicious changes.

Each kubeconfig manages its own RBAC and all resources inside kcp are named based on the UID of the Kubeconfig object. This ensures uniqueness all around and avoids having to merge desired RBACs into one ClusterRole(Binding) and unfiddle them when RBAC for one Kubeconfig is removed.

Notably, since the kcp-operator now has to talk with shards and the front-proxy, this PR modifies the local e2e setup to work like the CI e2e test: build an operator image and deploy it into kind, rather than running the operator on the host machine. This is a bit sad for quick debugging tests, but saves us from somehow having to either dynamically expose the pods through kind to the host, or rewriting URLs in the operator somehow.

What Type of PR Is This?

/kind feature

Related Issue(s)

Fixes #49

Release Notes

Add authorization options to Kubeconfigs: the operator can now grant permissions to access a workspace to make newly created Kubeconfigs immediately useful.

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from xrstf. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[xrstf]

/kind feature

[kcp-ci-bot]

@xrstf: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kcp-operator-test-e2e	af6dc14	link	true	/test pull-kcp-operator-test-e2e
pull-kcp-operator-test-e2e-canary	af6dc14	link	false	/test pull-kcp-operator-test-e2e-canary

Full PR test history

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.