Skip to content
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

Feature request: CLI flag on the gitops-server for disabling "suspend" button #3700

Open
ghost opened this issue May 14, 2023 · 8 comments
Open
Labels
type/enhancement New feature or request

Comments

@ghost
Copy link

ghost commented May 14, 2023

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!

@ghost ghost added the type/enhancement New feature or request label May 14, 2023
@yiannistri
Copy link
Contributor

@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.

@ghost
Copy link
Author

ghost commented May 16, 2023

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?

@yiannistri
Copy link
Contributor

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

@ghost
Copy link
Author

ghost commented May 17, 2023

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? 😁

@yiannistri
Copy link
Contributor

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.

@ghost
Copy link
Author

ghost commented May 18, 2023

Hi @yiannistri, I'm confused, where would I add an OPA Policy exactly?

@yiannistri
Copy link
Contributor

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.

@ghost
Copy link
Author

ghost commented May 19, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant