feat: Applications in any namespace #9755

jannfis · 2022-06-22T12:37:52Z

Apps in any Namespace

Description

This change enables Application resources to exist in any namespace allowed by configuration.

The feature is not enabled by default, and has to be explicitly enabled by the administrator (see below).

The change aims to be fully backwards compatible.

This is a rather large change. It comprises changes to the controller's reconciliation logic, the API server as well as changes to the CLI and the UI. I try to outline the changes and design decisions best I can in the below description.

This PR implements proposal #6409 and supersedes the PoC PR #6537

Some terminology

Control plane cluster - the cluster Argo CD is installed to
Control plane namespace - the namespace where Argo CD is installed to (where the application controller is running in)
Application - an Argo CD Application resource
Project or AppProject - an Argo CD AppProject resource
User - an ordinary Argo CD user with some permissions to e.g. create Applications via CLI or UI and who is restricted by Argo CD RBAC
Administrator - an Argo CD administrator with access to the control plane's namespace

Status

This change is beta-quality and could require some additional testing and eyes.

My suggestion is to merge it early and keep polishing it until 2.5 release. If at time of 2.5 release there still are some known issues, we make sure to document them properly.

Things that work

Current end-to-end test suite runs without any changes being made to the tests. The changes to the e2e test framework are done to support testing applications in namespaces other than the control plane's one.
Initial set of e2e tests with applications in a different namespace have been added (not yet complete)
UI support is not fully finished yet (most things work, needs fine tuning)
CLI support is near complete (end-to-end tests are passing)
Documentation is not yet written, as there may be additional changes derived from the feedback cycles

Known issues

During my tests, I have found a bug with the annotation tracking method that I wasn't able to fix yet. It affects the controller in not noticing changes to tracked resources on the cluster under certain circumstances, when application.resourceTrackingMethod is set to annotation. I'm not yet sure whether I introduced this bug, or if it's a general bug with the tracking method. Edit: This is indeed a bug with the tracking method, not introduced through this change (reproduced it on code from master branch) - will open separate issue for that. Edit 2: Issue for this Argo CD loses track of managed live resource when switching tracking method #9781

Things to do

Breaking changes

None of I'd be aware of right now. If you find one, please let me know.

Change details

Enabling the feature

By default, the feature is disabled. Administrators have to explicitly enable it by giving the --application-namespaces parameter to the workloads of argocd-server and argocd-application-controller.

Open questions:

Should this be a setting in argocd-cm rather than a command line parameter, so list of namespaces can be changed at runtime?

Allowed namespaces

The --application-namespaces parameter takes a comma-separated list of allowed namespaces as glob patterns. The pattern * enables all namespaces on the control plane's cluster. The control plane's namespace (usually argocd) is always enabled. It cannot be disabled.

For example, setting --application-namespaces app-team1-*,app-team2-* would allow the controller and the server to handle applications in namespaces starting with app-team1- and app-team2-, but not in the namespace app-team-3.

When the feature is enabled, controller and server are switched from namespaced mode (i.e. "get and watch resources only from the control plane's namespace") to all namespaces mode. One reason is, that to support glob patterns, we don't know the namespaces to operate on at initialisation time, and second we don't want to keep a separate lister or informer for each allowed namespace due to compute and complexity constraints. Instead, we check for enabled namespaces when using the lister.

Only namespaces in the control plane's cluster can host Applications. Hosting Application resources in remote clusters are out of scope for now.

If there are multiple instances of Argo CD installed to the same cluster, the behavior when more than one instance specifies same allowed namespace patterns (and have access to those namespaces) is undefined. This scenario should be avoided (needs to be documented).

Application names

Applications will now be referenced to as namespace/name in the CLI and the UI. If namespace is omitted, the control plane's namespace (argocd in most installations) will be assumed. That means when Argo CD is installed in the namespace argocd, the application names argocd/guestbook and guestbook are semantically the same. When Argo CD is installed in the namespace gitops, likewise the application names gitops/guestbook and guestbook are semantically the same.

A similar syntactic change has been made for the UI. For example, both of the following URLs would now refer to the same application in the UI:

https://argocd.example.com/applications/guestbook

and

https://argocd.example.com/applications/argocd/guestbook

For the API, all relevant endpoints now offer the (optional) parameter applicationNamespace to specify the source namespace of the Application. If this parameter is not set, the control plane's namespace will be assumed.

For example, to retrieve the application guestbook in the namespace foo via the REST API, the following call can be made

GET /api/v1/applications/guestbook?appNamespace=foo

The reason for implementing this as query parameter instead of in the path is actually a limitation of grpc-gateway, which does not allow two paths to the same resource.

These changes to referencing also mean that now there may be two or more applications with the same name of guestbook, when all of them exist in a different namespace. For example:

argocd app get ns1/guestbook
argocd app get ns2/guestbook
argocd app get guestbook

Would all refer to an application named guestbook, but each of them would be in different namespaces and are unique applications.

The tracking label

For applications in the control plane's namespace, nothing changes. That means that the application guestbook in the argocd namespace will still be using the value guestbook in the tracking label. This keeps backwards compatibility and ensures that no resync of resources has to happen when a version containing this change is deployed, or when the feature is being enabled.

For applications in other namespaces, the value of the tracking label will be a combination of the namespace and the application name, concatenated with the underscore character. That means the application guestbook in the namespace foo will use foo_guestbook as the tracking label's value. The underscore character was chosen for being unambigious in this context, as it is not allowed in Kubernetes resource name.

Because this can lead to values that exceed the maximum length for label values, it is recommended to use annotation method for tracking resources. When the string combined of namespace and application name exceeds the 63 characters limit for label values, Kubernetes throws an error when trying to manage resources of such applications with Argo CD using the label tracking method.

Project association for applications

AppProjects govern much of the permissions that are granted to an Application. For this reason, Argo CD API RBAC ensures that users can only associate to projects that they are allowed to. A typical Argo CD user has no access to the control plane's namespace in Kubernetes, and is only allowed to create applications using the API, where RBAC is enforced.

The goal of this change is to allow ordinary Argo CD users to manage their Applications in a declarative way, in their own namespaces on the control plane's cluster. But in the declarative way, an Application may associate to any AppProject by just setting the field .spec.project to the name of the appropriate project. This might allow users to escalate their privileges on the cluster.

In order to prevent this privilege escalation, an Argo CD administrator will have to configure the names of allowed namespaces in the project. For this, a new field has been introduced in the AppProject's spec: .spec.sourceNamespaces. An Application wanting to associate to a given project must exist in one of the namespaces defined in this field.

As an example, when .spec.sourceNamespaces for project proj is set to foo, the Application foo/app is allowed to associate to project proj, but the application bar/app is not.

The .spec.sourceNamespaces field supports pattern matching, i.e.

spec:
  sourceNamespaces:
  - team1-source
  - team2-*

would allow Applications in the team1-source namespace as well as in any namespace starting with team2- to associate with the project.

The check for a namespace to be allowed to associate to a project has been made an integral part of the controller's reconciliation logic. Administrators can revoke the permissions at any time by removing the namespace from the sourceNamespaces field of the AppProject, and the controller will then enforce it. When the controller finds an Application with a project association that is not allowed, it will refuse to perform any reconciliation activity.

For backwards compatibility, Applications in the control plane's namespace are allowed to associate to any project.

By default, no other namespaces are allowed.

How to test manually

Set ARGOCD_APPLICATION_NAMESPACES to a list of namespaces that should be allowed by API server and controller and run make start or make start-local, e.g:
```
ARGOCD_APPLICATION_NAMESPACES="argocd-*" make start
```
Create a new AppProject which has .spec.sourceNamespaces set to some allowed namespaces for that project (or modify the default project).
Create a new app in a different namespace, e.g. argocd app create argocd-test/test-app ...
Manage this app using the CLI or the UI
Try different things - different namespaces (including ones that are not allowed, etc), app deletion, declarative app creation in allowed namespaces and not allowed namespaces, etc

Open questions

Space for rent

Closes #3474

codecov · 2022-06-22T12:49:08Z

Codecov Report

Merging #9755 (c10a381) into master (af40d52) will decrease coverage by 0.09%.
The diff coverage is 37.66%.

@@            Coverage Diff             @@
##           master    #9755      +/-   ##
==========================================
- Coverage   46.18%   46.08%   -0.10%     
==========================================
  Files         226      228       +2     
  Lines       27581    27858     +277     
==========================================
+ Hits        12737    12839     +102     
- Misses      13124    13282     +158     
- Partials     1720     1737      +17

Impacted Files	Coverage Δ
cmd/argocd/commands/app_actions.go	`0.00% <0.00%> (ø)`
cmd/argocd/commands/app_resources.go	`7.75% <0.00%> (-0.73%)`	⬇️
cmd/util/project.go	`9.70% <0.00%> (-0.40%)`	⬇️
controller/cache/cache.go	`20.88% <0.00%> (ø)`
pkg/apiclient/apiclient.go	`0.95% <0.00%> (-0.02%)`	⬇️
server/application/terminal.go	`12.75% <0.00%> (-0.09%)`	⬇️
util/settings/settings.go	`51.36% <0.00%> (-0.06%)`	⬇️
cmd/argocd/commands/app.go	`19.52% <2.14%> (-0.90%)`	⬇️
controller/clusterinfoupdater.go	`33.33% <20.00%> (-2.26%)`	⬇️
pkg/apis/application/v1alpha1/types.go	`54.84% <36.36%> (+0.14%)`	⬆️
... and 15 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

JasonHao123 · 2022-06-28T06:14:06Z

For the tracking label thing for other namespace, maybe mutating webhook can be a better solution, means you don’t need to make any change in existing logic. Especially we use CRDs in such case

crenshaw-dev

Apologies on the repetition on one of the comments. If it's invalid, hopefully it's easy enough to dismiss them all.

Overall lgtm. I need to read your comments again and consider if/how RBAC will change.

cmd/argocd/commands/app.go

cmd/util/project.go

controller/appcontroller.go

crenshaw-dev · 2022-06-28T14:41:31Z

server/application/application.go

+	appName := syncReq.GetName()
+	appNs := s.appNamespaceOrDefault(syncReq.GetAppNamespace())
+	appIf := s.appclientset.ArgoprojV1alpha1().Applications(appNs)
+	a, err := appIf.Get(ctx, appName, metav1.GetOptions{})


Should we do an "is allowed namespace" check first?

Maybe "superficial check" as described above.

crenshaw-dev · 2022-06-28T14:41:54Z

server/application/application.go

+	appName := rollbackReq.GetName()
+	appNs := s.appNamespaceOrDefault(rollbackReq.GetAppNamespace())
+	appIf := s.appclientset.ArgoprojV1alpha1().Applications(appNs)
+	a, err := appIf.Get(ctx, appName, metav1.GetOptions{})


Should we do an "is allowed namespace" check first?

Maybe "superficial check" as described above.

crenshaw-dev · 2022-06-28T14:42:16Z

server/application/application.go

-	a, err := s.appclientset.ArgoprojV1alpha1().Applications(s.ns).Get(ctx, *termOpReq.Name, metav1.GetOptions{})
+	appName := termOpReq.GetName()
+	appNs := s.appNamespaceOrDefault(termOpReq.GetAppNamespace())
+	a, err := s.appclientset.ArgoprojV1alpha1().Applications(appNs).Get(ctx, appName, metav1.GetOptions{})


Should we do an "is allowed namespace" check first?

Maybe "superficial check" as described above.

crenshaw-dev · 2022-06-28T14:42:37Z

server/application/application.go

+	appName := q.GetName()
+	appNs := s.appNamespaceOrDefault(q.GetAppNamespace())
+	appIf := s.appclientset.ArgoprojV1alpha1().Applications(appNs)
+	a, err := appIf.Get(ctx, appName, metav1.GetOptions{})


Should we do an "is allowed namespace" check first?

Maybe "superficial check" as described above.

util/argo/resource_tracking.go

iamnoah · 2022-07-15T15:02:31Z

Curious about how this affects other resources (when declared outside of the control plane namespace):

AppProject - Suppose I created a namespace per environment, could I have projects: dev/default, staging/default, prod/default?
Secrets - the cluster and repository secrets being limited to their namespace seems like a natural security boundary.
Application Sets - Should probably be limited to their own namespace? Cluster, etc. secrets used by generators would presumably be limited to the namespace.

jannfis · 2022-07-18T10:19:13Z

Curious about how this affects other resources (when declared outside of the control plane namespace):

AppProject - Suppose I created a namespace per environment, could I have projects: dev/default, staging/default, prod/default?

AppProjects will not be allowed to exist in any other than the control plane's namespace, since they control much of the governance aspects of Argo CD. If we'd allow users to create AppProjects in their own namespaces, this would allow them to escalate privileges within Argo CD (and therefore, on the cluster). IMHO, managing AppProjects will always be an administrative task, not a user one.

Secrets - the cluster and repository secrets being limited to their namespace seems like a natural security boundary.

Access to clusters and repositories is governed by the AppProject, see above. This PR does not change the scope of secrets for cluster and repositories.

Application Sets - Should probably be limited to their own namespace? Cluster, etc. secrets used by generators would presumably be limited to the namespace.

Eventually, users could launch their own ApplicationSet controller(s) in any of the namespaces they're allowed to to generate Applications . These instances will not have access to any secrets in the Argo CD control plane's namespace, tho. So, especially cluster generators may not work. We need to think about a way to properly integrate ApplicationSet into this mechanism. OTOH, we could also extend the ApplicationSet controller to implement similar mechanisms as the application controller, i.e. watch for appset resources in the same namespace. However, for the first incarnation of this change, app set controller is out of scope.

iamnoah · 2022-07-18T14:38:16Z

AppProjects will not be allowed to exist in any other than the control plane's namespace, since they control much of the governance aspects of Argo CD. If we'd allow users to create AppProjects in their own namespaces, this would allow them to escalate privileges within Argo CD (and therefore, on the cluster). IMHO, managing AppProjects will always be an administrative task, not a user one.

I would expect namespaced AppProjects to have similar restrictions to namespaced apps. i.e., they can only be assigned to applications in the same namespace, can only access secrets from that namespace, etc. So there should be no way to escalate privileges beyond the namespace. Is there any reason that would not work? (if out of scope for this PR, I can understand that.)

jannfis · 2022-07-18T15:11:25Z

I would expect namespaced AppProjects to have similar restrictions to namespaced apps. i.e., they can only be assigned to applications in the same namespace, can only access secrets from that namespace, etc. So there should be no way to escalate privileges beyond the namespace. Is there any reason that would not work? (if out of scope for this PR, I can understand that.)

Currently, the AppProject restricts - among other things - what kind of resources (and their scope, i.e. cluster scoped or namespace scoped) an application is allowed to deploy, and where it is allowed to deploy (clusters, and namespaces in those clusters). IMHO, this control must not be given to the user. I'm not sure how we could properly design a governance model around this. But if you have ideas, I'm all ears :)

jannfis · 2022-07-19T15:26:51Z

@crenshaw-dev Thanks for the review! I have addressed almost all of your comments.

For the RBAC change (which has not yet been made), I was twisting my head. I see two possible options to extend the RBAC syntax to address applications:

project/namespace/name
namespace/project/name

I think option 1 would be the one to go for, as it provides the least amount of surprise. However, there are few problems due to the fact that our glob matcher doesn't treat the forward-slash as separator. So, */foobar would match the application name foobar in any project, and any namespace. Similarly, default/* would match any application in any namespace in the project default. I'm not sure if that'd be expected, but it would definitely be backwards compatible. To allow application foobar in the namespace barbar in any project, the RBAC identifier would look like */barbar/foobar. This behavior could lead to unwanted behavior, tho, if people forget about the namespace.

We could introduce a slightly breaking change here and provide / as the path separator. So, */foobar would actually never match. It would have to be */*/foobar or **/foobar.

Maybe you have some thoughts on all that?

crenshaw-dev · 2022-07-21T18:14:19Z

cmd/argocd/commands/app.go

@@ -180,6 +181,7 @@ func NewApplicationCreateCommand(clientOpts *argocdclient.ClientOptions) *cobra.
 	if err != nil {
 		log.Fatal(err)
 	}
+	command.Flags().StringVarP(&appNamespace, "app-namespace", "N", "", "Namespace where the application will be created in")


Will/should this default to "wherever the controller lives"?

crenshaw-dev · 2022-07-21T18:15:37Z

cmd/argocd/commands/app.go

 			errors.CheckError(err)
-			resources, err := appIf.ManagedResources(ctx, &applicationpkg.ResourcesQuery{ApplicationName: &appName})
+			resources, err := appIf.ManagedResources(context.Background(), &applicationpkg.ResourcesQuery{ApplicationName: &appName, AppNamespace: &appNs})


Any reason not to stick with ctx?

crenshaw-dev · 2022-07-21T18:18:09Z

cmd/argocd/commands/app.go

@@ -911,7 +925,7 @@ func findandPrintDiff(ctx context.Context, app *argoappv1.Application, resources
 			unstructureds = append(unstructureds, obj)
 		}
 		groupedObjs := groupObjsByKey(unstructureds, liveObjs, app.Spec.Destination.Namespace)
-		items = groupObjsForDiff(resources, groupedObjs, items, argoSettings, appName)
+		items = groupObjsForDiff(resources, groupedObjs, items, argoSettings, app.Name)


Why InstanceName above but just Name here?

crenshaw-dev · 2022-07-21T18:25:29Z

cmd/argocd/commands/app.go

@@ -1715,12 +1748,18 @@ func waitOnApplicationStatus(ctx context.Context, acdClient argocdclient.Client,
 	// time when the sync status lags behind when an operation completes
 	refresh := false

+	appRealName, appNs := argo.ParseAppQualifiedName(appName, "")


appRealName is kind of an odd name. What about renaming the func param to appQualifiedName and this to appName for consistency with other code?

crenshaw-dev · 2022-07-21T18:27:40Z

cmd/util/app.go

 	// read arguments
 	if len(args) == 1 {
 		if appName != "" && appName != args[0] {
 			return nil, fmt.Errorf("--name argument '%s' does not match app name %s", appName, args[0])
 		}
 		appName = args[0]
 	}
+	appName, appNs := argo.ParseAppQualifiedName(appName, "")


Maybe renamed the func param appQualifiedName for readability?

crenshaw-dev · 2022-07-22T14:05:05Z

server/application/application.go

+	appName := rollbackReq.GetName()
+	appNs := s.appNamespaceOrDefault(rollbackReq.GetAppNamespace())
+	appIf := s.appclientset.ArgoprojV1alpha1().Applications(appNs)
+	a, err := appIf.Get(ctx, appName, metav1.GetOptions{})


Maybe "superficial check" as described above.

crenshaw-dev · 2022-07-22T14:05:09Z

server/application/application.go

-	a, err := s.appclientset.ArgoprojV1alpha1().Applications(s.ns).Get(ctx, *termOpReq.Name, metav1.GetOptions{})
+	appName := termOpReq.GetName()
+	appNs := s.appNamespaceOrDefault(termOpReq.GetAppNamespace())
+	a, err := s.appclientset.ArgoprojV1alpha1().Applications(appNs).Get(ctx, appName, metav1.GetOptions{})


Maybe "superficial check" as described above.

crenshaw-dev · 2022-07-22T14:05:16Z

server/application/application.go

+	appName := q.GetName()
+	appNs := s.appNamespaceOrDefault(q.GetAppNamespace())
+	appIf := s.appclientset.ArgoprojV1alpha1().Applications(appNs)
+	a, err := appIf.Get(ctx, appName, metav1.GetOptions{})


Maybe "superficial check" as described above.

util/app/app.go

crenshaw-dev · 2022-07-22T14:12:11Z

util/argo/argo.go

+		return nil, err
+	}
+	if !proj.IsAppNamespacePermitted(app, ns) {
+		return nil, fmt.Errorf("application '%s' in namespace '%s' is not allowed to use project '%s'",


Maybe add ", because the project does not allow applications in that namespace" or something to clarify why it's disallowed.

crenshaw-dev · 2022-07-22T14:20:21Z

For the RBAC change (which has not yet been made), I was twisting my head. I see two possible options to extend the RBAC syntax to address applications:

project/namespace/name

namespace/project/name

I think option 1 would be the one to go for, as it provides the least amount of surprise. However, there are few problems due to the fact that our glob matcher doesn't treat the forward-slash as separator. So, /foobar would match the application name foobar in any project, and any namespace. Similarly, default/ would match any application in any namespace in the project default. I'm not sure if that'd be expected, but it would definitely be backwards compatible. To allow application foobar in the namespace barbar in any project, the RBAC identifier would look like */barbar/foobar. This behavior could lead to unwanted behavior, tho, if people forget about the namespace.

We could introduce a slightly breaking change here and provide / as the path separator. So, */foobar would actually never match. It would have to be //foobar or **/foobar.

I like option 1.

Considering the change without adding the separator:

*/app will match both project/app and project/namespace/app - I think I'm okay with that
project/* will match both project/app and /project/namespace/app - also seems fine
*/* and * will continue to match everything - makes sense

Since the admin has to opt in to adding namespaces, I think we can just add notes to the docs about how RBAC matching works. The behavior above seems fairly intuitive.

Am I correct that project/app will still match apps in the default ns? Or will the new RBAC have to be project/argocd/app?

zachaller · 2022-07-22T15:33:58Z

For the RBAC change (which has not yet been made), I was twisting my head. I see two possible options to extend the RBAC syntax to address applications:

project/namespace/name

namespace/project/name

I think option 1 would be the one to go for, as it provides the least amount of surprise. However, there are few problems due to the fact that our glob matcher doesn't treat the forward-slash as separator. So, /foobar would match the application name foobar in any project, and any namespace. Similarly, default/ would match any application in any namespace in the project default. I'm not sure if that'd be expected, but it would definitely be backwards compatible. To allow application foobar in the namespace barbar in any project, the RBAC identifier would look like */barbar/foobar. This behavior could lead to unwanted behavior, tho, if people forget about the namespace.
We could introduce a slightly breaking change here and provide / as the path separator. So, */foobar would actually never match. It would have to be //foobar or **/foobar.

I like option 1.

Considering the change without adding the separator:

*/app will match both project/app and project/namespace/app - I think I'm okay with that

project/* will match both project/app and /project/namespace/app - also seems fine

*/* and * will continue to match everything - makes sense

Since the admin has to opt in to adding namespaces, I think we can just add notes to the docs about how RBAC matching works. The behavior above seems fairly intuitive.

Am I correct that project/app will still match apps in the default ns? Or will the new RBAC have to be project/argocd/app?

I also agree with option 1. I think project/namespace/name makes more intuitive sense to an admin by sticking with the norm of generic to specific. I think the small breaking change in add the / as a seperator is also worth it.

crenshaw-dev · 2022-07-22T15:50:15Z

I think the small breaking change in add the / as a seperator is also worth it.

This part I'm less certain about, because I think it would break anything with fewer than two slashes (i.e. *, */*, */app, proj/*).

We could auto-upgrade those patterns on the backend:

* and */* -> */*/*]
project/* -> project/*/*
*/app -> */*/app

But there are some patterns which would be trickier to upgrade:

*-dev -> */*/*-dev
dev-* -> dev-*/*/*
proj/dev-* -> proj/*/dev-*
proj/*-dev -> proj/*/*-dev
nightmare-*-rbac-*-yikes -> I don't even know... probably a combination of a bunch of patterns

For typical patterns, I think auto-upgrade is easy. For atypical patterns, I think it's a pretty big challenge.

@jannfis what's the RBAC pattern for an Application in the argocd namespace (regardless of whether we add the separator)? proj/argocd/app or just proj/app?

crenshaw-dev · 2022-07-22T16:01:04Z

We could

Introduce an optional formatVersion field to argocd-rbac-cm (defaulting to v1 if not present)
Have v2 opt them in to validating for fully-slashed RBAC format and enabling the separator in casbin
Refuse to allow apps in non-argocd namespaces until the user changes their formatVersion to v2

FireDrunk · 2022-07-29T06:54:19Z

Can I test this with a specific image tag instead of manually compiling the source?

crenshaw-dev · 2022-07-29T15:45:48Z

@FireDrunk I think you'll have to compile. I don't believe images in PRs are pushed anywhere.

But the make image make target is very easy/reliable in my experience.

Signed-off-by: jannfis <jann@mistrust.net>

d7volker · 2022-11-03T14:02:58Z

@FireDrunk Thanks a lot for testing in this early stage and for providing feedback! Much appreciated!

The --application-namespaces parameter can contain wildcards. To enable all namespaces in the cluster where Argo CD is running in, you can use --application-namespaces "*", or to allow only a subset of namespaces you can use --application-namespaces dev-* to allow only namespaces prefixed with dev-. Then, you can also use any values for the sourceNamespaces setting in the AppProject,

As for the ClusterRole, good catch! The permissions should probably include create, delete , update and patch as well, I will submit a PR.

@jannfis: I currently testing out the new feature. I am hitting the same issue like described by @FireDrunk,

Unable to save changes: error updating application: applications.argoproj.io "myapp" is forbidden: 
User "system:serviceaccount:argocd:argocd-server" cannot update resource "applications" in API group "argoproj.io" in the namespace "myns"

I don't understand this. I mean I could extend the ClusterRoleBinding to an additional namespace. But I am asking about the sense.

I am using 2.5.1 migrated from 2.4.11

d7volker · 2022-11-03T14:44:37Z

Problem solved, a restart of the argocd-server pod did the trick.

pentago · 2022-11-25T17:04:13Z

How can one disable this functionality? Any chance of having a Helm chart option to disable/enable?

pentago · 2022-11-25T17:04:14Z

How can one disable this functionality? Any chance of having a Helm chart option to disable/enable?

crenshaw-dev · 2022-11-25T17:12:12Z

@pentago this feature is opt-in. If you haven’t configured additional application namespaces, the feature is disabled.

pentago · 2022-11-25T18:12:28Z

I ask this because in UI on app cards I see argocd/appname and its a bit confusing. If feature is disabled, the app name in web UI should be just appname instead of argocd/appname. Any chance of making it happen?

crenshaw-dev · 2022-11-25T18:19:41Z

@pentago ah yes that’s annoying. The fix has been merged, I hope to cut 2.5.3 with that fix Monday morning.

patrickbardo · 2023-03-15T15:08:09Z

Was wondering if it is possible to support declarative repository connections as secrets in other namespaces with this feature? More info here

jannfis mentioned this pull request Jun 22, 2022

feat: (PoC) Applications outside argocd namespace #6537

Closed

jannfis marked this pull request as ready for review June 22, 2022 14:38

jannfis force-pushed the feat/apps-in-any-namespace branch from 9e0a02c to b16bfb1 Compare June 27, 2022 06:46

crenshaw-dev mentioned this pull request Jun 27, 2022

Application not visible when deploying to other namespace than argocd #3847

Closed

3 tasks

crenshaw-dev requested changes Jun 28, 2022

View reviewed changes

crenshaw-dev requested changes Jul 22, 2022

View reviewed changes

crenshaw-dev mentioned this pull request Jul 28, 2022

proposal: Applications outside argocd namespace #6409

Merged

10 tasks

jannfis added 10 commits August 1, 2022 08:20

feat: Applications in any namespace

6aac75e

Signed-off-by: jannfis <jann@mistrust.net>

Fix typo in CI

3f20a8b

Signed-off-by: jannfis <jann@mistrust.net>

Create argocd-e2e-external namespace

e71d320

Signed-off-by: jannfis <jann@mistrust.net>

Update from codegen

6a2193b

Signed-off-by: jannfis <jann@mistrust.net>

Remove debug code

46f8bd0

Signed-off-by: jannfis <jann@mistrust.net>

Update help text for -N option to app create

60a1225

Signed-off-by: jannfis <jann@mistrust.net>

Wrap error when retrieving AppProject from cache

04cbff0

Signed-off-by: jannfis <jann@mistrust.net>

Check for controller namespace first before matching on additional ns

84b196c

Signed-off-by: jannfis <jann@mistrust.net>

Improve TestAppProjectIsSourceNamespacePermitted unit test

5f17811

Signed-off-by: jannfis <jann@mistrust.net>

Get rid of some debug leftovers

7509db8

Signed-off-by: jannfis <jann@mistrust.net>

TMaYaD mentioned this pull request Sep 21, 2022

Multi-namespace support for applicationset #10655

Closed

tongpu mentioned this pull request Sep 27, 2022

Add support for application namespaces argoproj-labs/argocd-operator#787

Open

ch-stark mentioned this pull request Sep 28, 2022

consider ArgoCD multitenancy enhancement ch-stark/gitops-rbac-example#14

Open

ishitasequeira mentioned this pull request Oct 25, 2022

feat: changes to support the feature apps in any namespaces argoproj-labs/argocd-operator#794

Merged

2 tasks

karlschriek mentioned this pull request Oct 26, 2022

Add compatiblity for "source_namespaces" introduced in ArgoCD v2.5.0 argoproj-labs/terraform-provider-argocd#212

Merged

robertbublik mentioned this pull request Oct 27, 2022

feat(argo-cd): Upgrade Argo CD to 2.5.0 argoproj/argo-helm#1568

Merged

6 tasks

waaghals mentioned this pull request Oct 28, 2022

Allow setting application namespace from ApplicationSet template #11104

Open

mrysavy mentioned this pull request Nov 2, 2022

ArgoCD doesn't respect application.namespaces #11116

Closed

3 tasks

This was referenced Nov 6, 2022

fix(argo-cd): Add missing ClusterRole permissions to argo-cd-server argoproj/argo-helm#1621

Merged

fix: add missing ClusterRole permissions to argo-cd-server #11210

Closed

danielhelfand mentioned this pull request Nov 8, 2022

argocd CLI uses wrong namespace #9123

Open

karlschriek mentioned this pull request Nov 9, 2022

Terminating sync leads to "error getting application by name" #11239

Closed

3 tasks

This was referenced Dec 6, 2022

DDO-2500 fix for ArgoCD cli now prefixing application names with namespace broadinstitute/terra-helmfile-images#43

Merged

DDO-2500 fix: argocd cli now prefixes application names with namespace broadinstitute/thelma#93

Merged

This was referenced Dec 9, 2022

[argo-cd] Application in any namespace | Synced with NO resources deployed argoproj/argo-helm#1695

Closed

Application in any namespace | Synced with NO resources deployed #11638

Open

iandelahorne mentioned this pull request Jan 11, 2023

UI: Links to Sub-applications in other namespace are broken #11945

Closed

cw-sakamoto mentioned this pull request Jan 26, 2023

[argoproj-crd]update application for each namespace chatwork/charts#280

Merged

1 task

karlschriek mentioned this pull request Mar 7, 2023

UI Errors: error getting application: applications.argoproj.io "xxxx" not found #12752

Closed

3 tasks

gnunn1 mentioned this pull request Feb 5, 2024

Promote Applications in Any Namespace to Stable #16189

Open

raghavi101 mentioned this pull request Feb 28, 2024

feat: add cli commands to add/delete sourceNamespaces from AppProject #17337

Merged

14 tasks

feat: Applications in any namespace #9755

feat: Applications in any namespace #9755

Conversation

jannfis commented Jun 22, 2022 • edited Loading

Apps in any Namespace

Description

Some terminology

Status

Things that work

Known issues

Things to do

Breaking changes

Change details

Enabling the feature

Allowed namespaces

Application names

The tracking label

Project association for applications

How to test manually

Open questions

codecov bot commented Jun 22, 2022 • edited Loading

Codecov Report

JasonHao123 commented Jun 28, 2022 • edited Loading

crenshaw-dev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iamnoah commented Jul 15, 2022

jannfis commented Jul 18, 2022

iamnoah commented Jul 18, 2022

jannfis commented Jul 18, 2022

jannfis commented Jul 19, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crenshaw-dev commented Jul 22, 2022

zachaller commented Jul 22, 2022 • edited Loading

crenshaw-dev commented Jul 22, 2022 • edited Loading

crenshaw-dev commented Jul 22, 2022

FireDrunk commented Jul 29, 2022 • edited Loading

crenshaw-dev commented Jul 29, 2022

d7volker commented Nov 3, 2022 • edited Loading

d7volker commented Nov 3, 2022

pentago commented Nov 25, 2022

pentago commented Nov 25, 2022

crenshaw-dev commented Nov 25, 2022

pentago commented Nov 25, 2022

crenshaw-dev commented Nov 25, 2022 • edited Loading

patrickbardo commented Mar 15, 2023

jannfis commented Jun 22, 2022 •

edited

Loading

codecov bot commented Jun 22, 2022 •

edited

Loading

JasonHao123 commented Jun 28, 2022 •

edited

Loading

zachaller commented Jul 22, 2022 •

edited

Loading

crenshaw-dev commented Jul 22, 2022 •

edited

Loading

FireDrunk commented Jul 29, 2022 •

edited

Loading

d7volker commented Nov 3, 2022 •

edited

Loading

crenshaw-dev commented Nov 25, 2022 •

edited

Loading