-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
application resource can be applied in any namespace #3474
Comments
This was briefly discussed today at the Argo CD & Rollouts Community Meeting during the Application Set proposal given by @jessesuen. |
Thank you |
I would like to add the following suggestion. If you set a sort of scrape label like prometheus has on the namespace i.e. |
@rumstead any update on this? We also need it... |
Last I heard the app set hasn't been moved into AroCD yet. Though I am not the best person to give an update. |
Is there any progress? Similar to @yhaenggi we would also really like to have this implemented. Centrally we're controlling the |
Hi @alexmt ! I've started taking a look at this. In the upcoming milestone , I'm planning to make an enhancement proposal ( we can all feel free to +1/-1 it :) ) on this area. We may not get to implementing it, but I'd like to get a design going. Could we mark it for the upcoming milestone as 'design only' effort ? |
Can someone explain why the current behaviour was implemented as it is? |
@juv, Argo CD provides a single control plane that manages resources in multiple clusters. Having Applications CRDs in control plane cluster in one namespace allows us to implement UI/API that presents the state of all managed resources at once. If we store applications CRDs in multiple managed clusters it will be really difficult to fetch application status information. However I totally agree with the use case described in this ticket: it would be very nice to let end users create "apps" in target namespaces and "self service" argocd management. I've been working on PoC that resolves that issue for couple weeks. Hope to finish it this weekend and will present to the community. |
There are two distinct areas :
Here's how I see it :) |
I had some thoughts on this as well, and I think some of the major problems to solve are pointed out below: The relationship between AppProject and Application. The AppProject provides governance to what an Application is allowed to do in the cluster, which repositories it may access etc. In the current state, Application CRs can be created in the cluster without enforcing what values the One possible solution would be to either enhance the AppProject CRD with a new field, e.g.
would allow Applications from each namespace in each cluster to specify the Also, all that being written, I think we should really have the Missing connection to a remote cluster. What happens when the connection to a remote cluster that holds Application CRs goes away? I think this is what @alexmt is tackling right now, and I believe this could be mitigated using some caching mechanisms on the Argo CD control plane side. However, since we consider Argo CD stateless, and the cache to be rebuildable at any time, this could pose some very nasty surprises imho and Applications to temporarily disappear. |
From my perspective, the experience I'm looking for is :
What determines whether (4) is allowed ? |
I'm wondering how that could possibly work. I think there are a multitude of constraints that prevent that from working:
|
The information could be extracted from an admission controller payload and persisted in an annotation on the Application CR. Only the webhook will be allowed to modify that annotation.
Before applying changes to a cluster, always do an SubjectAccessReview to see if user
We are potentially letting a cluster user do things which she wasn't allowed to do in the first place by the cluster admin. Based on what the ArgoCD admin decided, we are letting the user create workloads. Effectively, we are trusting the Argo CD RBAC system to make a good decision. I'm suggesting that if the user exists on the cluster, why not use the Kubernetes RBAC system to make the decision. :-)
The CI would be authenticating to the cluster in some way. The user/service account with which the CI authenticates should have the necessary privileges. |
But what if the organization doesn't even want to have users with those kind of privileges? IMHO, one of the neat things of having a system like Argo CD is, that you can get rid of all of those users jumping around with
From my point of view, the CI would have the right to create an The application controller makes sure that only resources can be created that are allowed by the AppProject associated with any application. I do agree that the current approach of having the application controller having full cluster level access for every operation is not good, however, I think inheriting permissions from the user who creates an There is this (unfortunately) stale PR (#3377) which proposed user impersonation for the application controller, bound to an AppProject. I haven't tested whether this is possible, or what side-effects it would bring, but it could allow the application controller to operate with a given ServiceAccount (and therefore, K8s RBAC restrictions) when reconciling applications. With such a method, we could get rid of resource restrictions within Argo CD (e.g. those imposed by the AppProject), and manage & impose those restrictions using K8s native methods. |
Agreed, the existing model solves the problem for organizations that don't necessarily want their users to be exposed to Kubernetes.
The CI already has access to create other things, not by itself, rather via ArgoCD Application CR. So, effectively the permission management is not the native Kubernetes one, rather the ArgoCD one.
As an example, I am allowed to do everything on three namespaces in a cluster - I need something that would sync manifests within the realm of the namespaces I already have access to. :) |
Isn't this a scenario we want to get away from? :)
That's correct, and the CI (or any other user) would have these privileges through an intermediary, Argo CD. And only for resources stored in Git, and every change would be traceable and auditable. By granting the user corresponding privileges on the control plane, you would effectively allow changes outside of this pattern.
That's also correct, and that's why I wanted to bring #3377 into play :) |
Great to see that this thread has gotten some traction! I really like the discussion. To come back on the question from @peterbosalliandercom:
Yes, right now developers of different teams/products, and therefore different namespaces, all have essentially the power to modify the From @sbose78:
Exactly, and to provide some more context why we would like to see this, let me explain our use-case. Centrally, from the Platform/Admin team, we control the Argo CD installation/configuration. However, we try to give as much 'do-it-yourself' control to teams to control their own deployments using Argo CD. We control centrally what a team is allowed to synchronize (i.e. the repo, the namespace, specific non-namespaced resources, or even blacklist namespaced resources) with an
100% agreed. In our set up, generally users only have What I have been wondering though, is there a reason why Another point to consider, imagine that |
I think the |
What do you guys think about an
Additionally, it would be awesome if Argo CD builds upon native K8s RBAC. Though I think that is a topic to discuss outside of the issue at hand regarding the namespacing of |
Hi @mvbakker |
@alexmt Any progressing on this? This becomes a main pain point for our use case. We have tested that users can easily destroy or crush others' service by creating an application with same name and setup auto-sync policy. In a multi-tenant environment, It's a big risk and also it's hard to prevent without sacrificing user experience/flexibility. We need either global naming mechanism or allowing the application CR to be in different namespaces. So that users' impact/interaction are isolated. |
Summary
We would like the ability for argoCD to recognise any
application
resource that has been applied across the cluster and not just within the namespace where ArgoCD has been deployed.Motivation
We are working on producing a multi-tenant implementation in our cluster and to do this, we have implemented a controller for handling all of these tenants. There is the use case where the same application will be applied in multiple different tenants (which will generally be a grouping of namespaces). Currently, as all application CRs are present in the argocd namespace, these cannot share the same name.
If applications were picked up from all namespaces, we could begin to store the application CR in the relevant tenants namespace instead of having to rename the application.
Proposal
How do you think this should be implemented?
In the ArgoCD spec allow specifying a
scope
field which allows argo to scan the entire cluster or just the namespace.I'm sure you guys have a justification as to why you are limiting the application resource to only the namespace where argocd has been deployed and I'm curious as to why.
Cheers,
Art
The text was updated successfully, but these errors were encountered: