-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ClusterRoles for CSR approval modes to RBAC bootstrappolicy #48191
Comments
Wouldn't we expect and encourage people using the CSR capability for their nodes to use node identities that match the node authorizer, in which case we won't need the client or server renewal CSR roles? |
The node authorizer doesn't grant these, since otherwise you could never prevent a compromised node from renewing its credentials |
Realistically, with these roles you still wouldn't. People would grant them to the node group, not each individual node, but I guess that would be a tradeoff for the deployment mechanism. |
You could individually revoke this role from the group and stop renewals without disrupting regular operation |
I can definitely see myself revoking a binding from Anyway, this issue is more "should we create these by default or not". |
Creating the roles seems reasonable. I don't think I want bindings. I think the binding should be up the particular deployer. |
Perfect, that's exactly my proposal. I'll go ahead and make this change... |
/assign @mikedanese |
@mikedanese are you working on this or should I send a PR? |
Automatic merge from submit-queue (batch tested with PRs 49284, 49555, 47639, 49526, 49724) Add clusterroles for approving CSRs easily **What this PR does / why we need it**: Adds ClusterRoles for CSR approving. Currently consumers like kubeadm and GKE have to create these rules by themselves, but are doing it slightly differently which leads to sprawl. Instead, the ClusterRoles are created by core, and the actual bindings created by respective deployment method. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # fixes #48191 **Special notes for your reviewer**: **Release note**: ```release-note The API Server now automatically creates RBAC ClusterRoles for CSR approving. Each deployment method should bind users/groups to the ClusterRoles if they are using this feature. ``` cc @kubernetes/sig-auth-pr-reviews @kubernetes/sig-cluster-lifecycle-pr-reviews
/kind feature
From: kubernetes/website#4208
Would it make sense to add these rules to the bootstrappolicy? To me they seem generic enough, and they wouldn't bind to something. Consumers can do the binding to their subjects as they like.
I'm asking because it's already duplicated twice for two early adopters:
https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/rbac/kubelet-certificate-management.yaml
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/apiconfig/clusterroles.go
I don't think those ClusterRoles are specific to kubeadm and GKE at all; but the ClusterRoleBindings will surely be, so therefore we'd create the roles but not the bindings.
@kubernetes/sig-auth-feature-requests
The text was updated successfully, but these errors were encountered: