-
Notifications
You must be signed in to change notification settings - Fork 160
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
Minimal rbac to view and reconcile resources in UI #3702
Comments
@adberger Thanks for the report. This is a known issue, and one that cropped up for me again in a different form this week. The root cause of this is how we determine whether a user can "see" a namespace: weave-gitops/core/nsaccess/nsaccess.go Line 67 in f69ed59
Kubernetes doesn't have a concept of "yes you can see this namespace", because it only knows about verbs against kinds in a namespace, so we layered on the access logic to convert it to a bool. We aren't handling the |
@jpellizzari I see, that's unfortunate. We now do it like this for the moment:
The users can see everything, but only sync their resources. |
I'm afraid we need more time to test this change. |
I think the problem in the original report is that Weave GitOps wants to be able to see groups and resources in addition to "sources.toolkit.fluxcd.io" and "kustomization.toolkit.fluxcd.io" (the requirements are expressed as rules in https://github.com/weaveworks/weave-gitops/blob/main/core/nsaccess/nsaccess.go). Having resourceNames in a rule doesn't cause problems -- it's present in the example of RBAC that does work. |
Sure, my provided example works, but with this configured, every user see every flux resource of a namespace in the UI (which is not intended) but can only sync their resources (which is intended). I would like to specify an rbac like this:
|
Right, the access you need to give people so they can see namespaces in the UI, is (much) more than just I can see why having more access makes the display richer (you can display the status of workloads, say), but you ought to be able to see your stuff in the UI if you can access it via RBAC. "Ought" as in: Weave GitOps does not do this, and it would be better if it did. |
Any progress on this concern? |
@bigkevmcd and @foot Can you please take a look at this? |
@LappleApple I guess we could take the original attempt, and improve it by looking for the presence of the named resources ( Not sure when we would get a chance to do this tho' |
Hi there, I have check today the RBAC a bit because we want not to grant permissions for "secrets" in general and thus i have check where this is really needed. I have found a reference here: https://github.com/weaveworks/weave-gitops/blob/main/core/nsaccess/nsaccess.go#L21 So i have tested what happens with a "fake" permission here like this:
so i grant access to only a single not existing secret (which is like no access) but it looks like this is "fair enough" for the "nsaccess" checker.. So i would suggest to remove the "secrets" from the nsaccess check and also from the minimal rbac if there is really no need for it. |
@erikgb @mproffitt |
I agree it would be ideal to not grant cluster-wide access to secrets - if possible. Do we have any idea why this RBAC was given in the first place? If it's only to check if a user has access to a namespace, there are better solutions now with |
I had a closer look at this now, and I don't understand why cluster-wide read access to secrets is required. The code referred to by @eloo-abi is running with the impersonate client as far as I can reason. It is impossible to see from the Git log why this permission was added in the first place. It's been part of the Helm chart since the beginning. I would suggest a "feature gate" Helm value to disable the cluster-wide read access to secrets. Then our users can use this toggle to see if something breaks without it. We can eventually change the default after a couple of releases. I/we would also be interested in removing this permission, so I would enable this new toggle once available in a release. Does this sound like a good start @eloo-abi? I can prepare a PR to make it even clearer what I mean. |
I just opened #4659. PTAL! |
@erikgb yes this sounds good to disable that feature.. but i guess your PR will not solve the main problem as the nsaccess will still check for the permissions to secrets.. so its more important to remove the secrets resource from the nsaccess code |
Yes, we have to do more in this area to fully fix the problem. I think the whole nsaccess code should be reviewed and improved. Since ww-gitops impersonates the user, I think this check could be a lot more lightweight - since the check is not authorative. Checking RBAC to read a named namespace should be sufficient IMO, but we need to think/work more on this before performing any changes. |
I just opened #4666 to address this issue. Please take a look an tell me what you think! |
Hi there
We are currently trying to limit the flux resources which a specific user/group can see & use (e.g. sync).
We tried to apply the following role, but the user doesn't see any resources matching the names specified.
The following requests over kubectl work:
Additionally setting
according to the docs, the user can see "too much".
The text was updated successfully, but these errors were encountered: