Open sanzenwin opened 3 years ago
There should be the same SSO and RBAC possibilities as you already implemented at other products. @alexec - probably you can help.
Interesting. SSO+RBAC was very time consuming to implement in Argo Workflows. I would not approach it the same way again. I would use Gin if I started again from scratch:
https://developer.okta.com/blog/2021/02/17/building-and-securing-a-go-and-gin-web-application
hi, @alexec thank you for the replay! ArgoCD becomes quite popular in our time because it brings new possibilities and solves many old-known problems. I believe that with the possibilities for secure login you can improve the customer journey for argo-rollouts! It is a super useful tool and taking into account that you guys already implemented this functionality for another product I believe, that this time it would be less painful and time-consuming. Hope you would have a chance to implement this request.
Not having dashboard authentication when installed on the cluster is major blocker for customers using rollouts in production clusters Really looking forward on this enhancement
@alexec any update here? Seems like it should be easy to put dex or something similar in front of this?
@alexec Do you have any update or roadmap for this? Really like the Rollouts dashboard, but I cannot public it to the outside because of lacking authentication
Currently, I am using the promote function of ArgoCD as a workaround
This issue is stale because it has been open 60 days with no activity.
@alexec Do you have any update or roadmap for this? Really like the Rollouts dashboard, but I cannot public it to the outside because of lacking authentication
Currently, I am using the promote function of ArgoCD as a workaround
same thing here
This issue is stale because it has been open 60 days with no activity.
I'm also very interested in this. It is possible to use http auth through an ingress controller as a way to put some kind of authentication in front of the dashboard, but having auth built into the dashboard would be way better.
+
Not having dashboard authentication when installed on the cluster is major blocker for customers using rollouts in production clusters Really looking forward on this enhancement
same thing here
I'm also very interested in this.
I would like to get this feature as well
I would be very interested in this feature as well, why argo workflows UI has it ? cannot we just copy the code from argo workflows into the rollouts to have the same SSO mechanism ?
If I need to contribute I would be glad to help but copying the code from argo workflows, not sure if it's a good PR.
I'm also very interested in this. Found various threads about this feature request.
@alexmt suggested to use argo-rollout-extension to embed rollout dashboard into Argo CD and re-use Argo CD's sso + multi tenancy feature. [source] Sounds like someone ran into issue about missing 'rollback' button from the dashboard with that approach (as of 4/26/23).
However, my team is not using Argo CD and wonder if there would be an Argo Rollout only solution without having to bring in Argo CD.
@david6983: Did you end up creating a MR for re-using the Workflows sso code in Rollouts?
@alexec: You mentioned that it was very time consuming to implement sso+rbac in Argo Workflows. But do you see any problem of reusing that code in Rollouts?
Add me as an interested party. We're about to start using rollouts for canary deployments but can't expose the dashboard until there is some way to limit to authorized users.
Any updates on this?
For all the people that have upvoted this, could you please explain what exactly is the end goal here?
Would you like to see
If it is just authentication for a production environment, the dashboard is just a standard Kubernetes application. You can secure it like any other Kubernetes application using an ingress, service mesh, gateway or auth mechanism. Or the issue is that we are missing documentation on how to do that?
For my part, I'd want RBAC so we can control who has access to the dashboard. We only want approved people able to restart/rollback rollouts.
Both . Only approved people for rollback and centralised access to rollout dashboard like we can expose argocd via ingress / direct integration in argocd itself without a need of extension.
currently we authenticate argocd via google sso , need same setup for rollout dasboard also so can provide granular permission.
RBAC is the key piece missing here. As mentioned, it's straightforward to put the GUI behind something like oauth-proxy etc. Issue then becomes anyone that's authenticated "has sudo" over deployments. So our use case requires RBAC to assign team and individual permissions so the dash becomes read-only, can only start rollouts but not stop/delete them etc.
Same here: RBAC to give different access control to different groups.
Hello, Argo community,
I have been looking at the comments on this issue for some days and decided to try working on it.
First of all, before implementing anything, I made a quick study to check what we could do to implement the RBAC system.
You will find below my notes. I am looking forward to some reviews first.
rollout
action/argoproj.io/v1alpha1/Rollout/updatecontainer
actions
action/argoproj.io/v1alpha1/Rollout/restart
action/argoproj.io/v1alpha1/Rollout/retry
action/argoproj.io/v1alpha1/Rollout/abort
action/argoproj.io/v1alpha1/Rollout/promote
action/argoproj.io/v1alpha1/Rollout/promotefull
We could implement the same roles based on Argo CD with 2 built-in policies
role:readonly
- read-only access to all resourcesrole:admin
- unrestricted access to all resourcesAbility to create custom roles using policies based on the same mechanism of Argo CD (Configmap)
policy.tester-overlay.csv: |
p, role:tester, rollouts, action/argoproj.io/v1alpha1/Rollout/promote, my-app-namespace/*, allow
p, role:tester, rollouts, get, my-app-namespace/*, allow
g, my-org:team-qa, role:tester
On the UI, if no access —> we disable the buttons or the input boxes
@kostis-codefresh +1 for both.
I think we could split this issue into 2 issues / PRs:
I haven't looked at Argo workflows in a long time, but I seem to recall it supports authentication via ArgoCD's dex. It would be ideal to not have to reinvent the wheel with rollouts. It'd be super if all 3 major Argo (CD, rollouts, workflows) tools worked the same way when it comes to authentication and RBAC.
I agree @bojanraic, That's why I suggested implementing the same type of authentication as Argo CD. However, we should be able to log in using SSO without installing Argo CD.
Hi @david6983 when can we expect this to be released? Much waiting feature.
Hello @NITHIN-JOHN-GEORGE , will try my best to do it within next 2 months
@david6983 hi man, are you still working on this ? I need this feature too. I want help you to do this . Can we copy similar logic from argocd first and then iterate it, so that we can use it quickly?
Hello @Sn0rt, yes working on it since last week. I will follow the same logic like argo workflow.
So far I almost finish to edit the server to add SSO. I am working on the RBAC server and then I will do UI.
I will open a draft PR soon.
I will update later this week 💪
Nice to see some movement on this finally! Thanks for picking it up.
Love Argo Rollouts, but lack of RBAC is blocking us releasing the dashboard internally. We also really need finer-grained control over actions-- it would be helpful to be able to promote/abort/retry and see to analysis results without allowing changing the container image.
can't wait to have this feature soon! my use case: Our team want to control and audit who can "promote" the rollout promotion
+1 , most awaiting one.
On Sun, 7 Jul 2024, 1:38 pm Ninad, @.***> wrote:
can't wait to have this feature soon! my use case: Our team want to control and audit who can "promote" the rollout promotion
— Reply to this email directly, view it on GitHub https://github.com/argoproj/argo-rollouts/issues/1323#issuecomment-2212363745, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW47KSPJA6OBTEYMYQPHQIDZLDZQ3AVCNFSM47X2JS5KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRRGIZTMMZXGQ2Q . You are receiving this because you were mentioned.Message ID: @.***>
@NiniiGit will take this in consideration to see if it fits in the rbac model.
Please allow me some time guys 💪
can't wait to have this feature soon! my use case: Our team want to control and audit who can "promote" the rollout promotion
Same here at our company. Auditing users and controlling promotion via RBAC would be really interesting.
Hi everyone! Any updates on this? Is there anything i can do to help? Thanks in advance...
Hello @Sn0rt, yes working on it since last week. I will follow the same logic like argo workflow.
So far I almost finish to edit the server to add SSO. I am working on the RBAC server and then I will do UI.
I will open a draft PR soon.
I will update later this week 💪
Hi everyone! Any updates on this? Is there anything i can do to help? Thanks in advance...
Hello @Sn0rt, yes working on it since last week. I will follow the same logic like argo workflow. So far I almost finish to edit the server to add SSO. I am working on the RBAC server and then I will do UI. I will open a draft PR soon. I will update later this week 💪
+1
Hello I started to draft in local some experimentation
I am currently stuck with Webpack
I started to add the SSO authentication in the server, then when I was trying to build the UI without modification, I got stuck on compilation. It's been a few weeks I am trying to solve the issue!
Hey @david6983, Argo Rollouts already lives in a Kubernetes cluster that itself has an SSO and RBAC mechanism. I think one of the benefit of rollout is to focus on providing an alternative to the Deployment resource with more progressive delivery capabilities. Adding a custom SSO, RBAC, user management, Dex, etc. adds a lot of overhead to the project. Just like there is no complex UI as part of the Kubernetes deployment controller, I don't think there should be one dedicated to Argo Rollouts, or at least not as part of this project, because it could easily be isolated in a project of it's own, while this project focus on the controller, but that is my personal opinion.
If the goal is to add authentication to the current dashboard of this project, I think this is worth doing and the authentication work could behave in a way similar to the Kubernetes dashboard, using the Kubernetes SSO and RBAC on the cluster.
From what I can read of the use cases above, it should be achievable using native Kubernetes RBAC. Although I think rollout would need changes so actions are available as a sub-resources, similar to (pods/log
, pods/exec
).
I also agree with @agaudreault I think the maintenance burden on the project for this feature far outweighs the benefit. I would be willing to work on enabling any feature in rollouts that would be needed to support this as an argoproj-labs project if there is anything needed.
Today, rollouts has an API it is the Kubernetes API. The Kubernetes API has enough RBAC control with namespace to generally do what needs to be done minus named resource permissions (aka the boundary is the namespace). Any service should be able to wrap the k8s API and put permissions behind it. It would be fairly easy to actually rip out the current dashboard from the controller today as well. I see it as a bit of an anti-pattern to provide a big backdoor to Kuberentes RBAC which is what ArgoCD does today as well. Tt has a place but there are people that would also prefer for ArgoCD to work more closely with K8s RBAC instead of being a big backdoor with a second set of permissions to manage.
That said I would be open for a built in authentication method that Workflows has, which is passing in an k8s token. This could be used for hosted dashboards so developers do not have to run the dashboard locally but still have the permissions they normally would get with k8s.
Argo CD lead here. My recommendation: be extremely cuatious.
Auth in Argo CD is incredibly costly to maintain. Much of the code depends on external services which are difficult or impossible to mock for testing. There are a number of Argo CD PKCE-related PRs open right now that are hung up waiting for the reviewer to get access to the necessary test infrastructure. It's easy to miss something during implementation and create a vulnerability. Auth vulnerabilities in Argo CD can take weeks of developer time to assess and resolve.
Argo CD averages ~400 contributions a week by ~125 contributors. Argo Rollouts receives about a tenth of that for both metrics. The Argo CD core maintenance team (top contributors representing 50% of total contributions in the last 12mo) is 15 people from 3 companies. The Argo Rollouts team is more like 4 people and 1 company.
Taking on a custom auth system is taking on a massive responsibility. It should be done with great care, if at all.
Hello @crenshaw-dev, @zachaller @agaudreault,
Thank you for your comments,
I totally agree with you what you said. I didn't realise while working on this locally the cost of maintenance of this feature for a small project.
From your inputs and user requirements above in this issue, what could we provide to easily add authentication and RBACs permissions on the dashboard without adding too much complexity to the code?
Looking forward to hear from you.
On another note, I was glad to at least try to start building something with the code base of Argo Rollout. Now I have a better understanding of the tool and how it was developed.
@david6983 Really glad you enjoyed learning about the rollouts codebase. Your PR was a non-trivial amount of work and effort. I would love to work with you on getting something that works for you as far as authentication goes. One of the features that I do think we can do upstream (in the rollouts codebase) would be to pass k8s authentication on to a hosted dashboard so that we impersonate the Kubernetes user instead of using a a k8s service account to talk to Kubernetes for the dashboard. Argo Workflows calls this client auth and you can get a token via the cli of your user account using this.
If you do need separation of Rollout RBAC within the same namespace having some API wrapper is probably required. I would be willing to help you get an argoproj-labs project going for a authenticated dashboard if that is something that interests you as well.
Let me know what your main goals are trying to accomplish with adding auth and we can figure something out.
Very interesting, let me get a deeper look at what you suggested and I will come back to you.
Sign in dashboard with token.
Refer to: https://github.com/argoproj/argo-workflows/issues/1813