-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Minimize RBAC roles for controllers #6554
Comments
We should be very careful. Not all verbs can be easily inferred from just reading the controller code:
|
One simplification I did in the past is to categorize verbs into groups:
Essentially once we need one of them we just add the entire group. This simplifies it a bit. For example, once we use If we are overly strict we risk missing a call somewhere, and if that call is only rarely used in edge cases we might not catch that case in e2e tests. I think we have to balance minimal roles vs the risk of breaking something. Especially given that even with minimal roles per reconciler the whole controller will still have a lot of rights. |
That seems like a sensible approach. My impression is that we probably have create in a few places it shouldn't be. I think we have update in a lot of places where it's not used, but we're using patch so it doesn't matter. I'm also thinking this could be something pushed to the next API rev. |
I think it's independent of our API version bump as it just affects the permissions of our controller and not the APIs/CRDs. |
I didn't mean to say it's dependent on a rev, more that we could do it as part of a future overall API revision as it's not urgent now IMO |
We can use also tools like https://github.com/liggitt/audit2rbac to check what is actually used |
Good idea, but I think we should only use it as additional info not as a reference, otherwise this means we have to hit all edge cases to be safe. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/lifecycle frozen /help |
@fabriziopandini: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed In response to this:
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. |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
/kind cleanup |
It is still worth to audit the code to figure out if there is something suspicious in our permissions |
/assign |
Following on from ##6510 (comment)
In Cluster API today we create RBAC manifests which are generated using kubebuilder tools. e.g.
cluster-api/internal/controllers/clusterclass/clusterclass_controller.go
Lines 42 to 44 in 626ab4d
Many of our controllers seem to generate overly broad RBAC for themselves. e.g. many have the create verb when it is not used.
Removing these roles should have no impact on functitonality, minimize the capabilities of our controllers from a security perspective, and make our RBAC manifests more descriptive about what our controllers are actually doing.
We should audit the following controllers to minimize their RBAC roles:
The text was updated successfully, but these errors were encountered: