Feature request: CLI flag on the gitops-server for disabling "suspend" button
Hi, I'd like to deploy the dashboard in my company in a way that everybody can use it for viewing things and syncing Flux objects, but I don't want to allow anybody to use the "suspend" (pause) button.
It'd be nice if the gitops-server had a CLI flag for disabling the "suspend" button, this way I don't need to worry about authentication and can use admin/admin for username and password (even better would be a way for starting the server with authn disabled).
I'd like to file a pull request for this feature, would that be accepted? Thanks in advance!
@aristapimenta thanks for using Weave GitOps and for sharing your use case.
My understanding is that you want to provide a view-only dashboard for all company users, without letting anyone interfere with the reconciliation loop. In my opinion, this is best achieved through tight control of RBAC permissions: removing the patch verb from the wego-admin-role for Flux objects would result in the admin user not being able to update these resources and suspend the reconciliation process.
The above would be required even if we implemented your suggestion, since hiding a button in the UI does not imply that a bad actor can no longer suspend the reconciliation process through the API.
Sorry, when I say disabling the button on the UI I also meant disabling the feature on the server side so the server won't process the requests issued from the browser when someone clicks on the "suspend" button, of course.
But yeah the RBAC solution sounds great! Thanks!
I would also like to allow people triggering reconciliations (the "sync" button), but not suspending them. Can I make this distinction via RBAC?
Sorry, when I say disabling the button on the UI I also meant disabling the feature on the server side so the server won't process the requests issued from the browser when someone clicks on the "suspend" button, of course.
I'm sorry, I guess I misunderstood the scope of your suggestion 😅 . Perhaps we could conditially expose the API endpoint used for Suspend/Resume but the change would not be trivial as we also need a way of telling the UI to hide the buttons conditionally at runtime. I may be wrong about this but I don't think we have a mechanism in place to do this yet.
I would also like to allow people triggering reconciliations (the "sync" button), but not suspending them. Can I make this distinction via RBAC?
Unfortunately, I don't think this is possible via RBAC since both operations, Sync and Suspend/Resume, require updating a Flux resource. In the case of Sync, we need to add an annotation to a Flux resource in order to trigger a reconciliation and in the case of Suspend/Resume we need to set the spec.suspend field of a Flux resource to a boolean value.
cc @JamWils in case you have other ideas
Perhaps we could conditially expose the API endpoint used for Suspend/Resume but the change would not be trivial as we also need a way of telling the UI to hide the buttons conditionally at runtime. I may be wrong about this but I don't think we have a mechanism in place to do this yet.
Can I take a stab? :grin:
Hey @aristapimenta while this is a reasonable request, we would prefer to rely on Kubernetes RBAC to solve this and avoid writing and maintaining code that supports a read-only setup. We think that introducing a read-only mode will eventually result in adding checks throughout the codebase and we prefer to avoid that extra complexity.
One approach to work around the RBAC limitation mentioned above is to use an OPA Policy which would allow the annotation to be set (allowing sync) without changing the spec.
Hi @yiannistri, I'm confused, where would I add an OPA Policy exactly?
You would need to install Gatekeeper in your cluster and then add a ConstraintTemplate/Constraint CRD (presumably via GitOps) which inspects the Flux resource being updated (by the admin user) and denies the operation if the spec is being changed (so Suspend/Resume buttons won't do anything) but allows it if a specific annotation is being set (so Sync button works). You would need to write the logic in Rego as part of the ConstraintTemplate.
It requires a bit of effort but it may solve your problem.
I don't want to prevent Flux objects from being suspended on the cluster level. I still wanna be able to use flux suspend, SREs are gonna need it, for example.
I just want to prevent Flux objects from being suspended on the GitOps UI, which I want to be available for everybody in the dev team, being the friendlier option as it is.
Okay, I already have Gatekeeper in my stack. So with Gatekeeper I'm even able to inspect the user making the update on the k8s object? I didn't know this part, I thought we could only check the k8s object spec. Really good to know! Thanks!! I will update this thread once I'm able to test this setup.