Argo-cd: Destination namespace is not enforced

[yann-soubeyrand]

Describe the bug

When adding an application with a specific destination namespace dest-ns, if the manifests for this application contain resources with another namespace manifest-ns in their metadata, Argo CD will try to deploy these resources to the manifest-ns namespace.

To Reproduce

1. Create two namespaces, test-ns and ingress-nginx: kubectl create ns test-ns; kubectl create ns ingress-nginx.
2. Add a new application with the following parameters:
   
   
   
   • repository: https://github.com/kubernetes/ingress-nginx.git/
   
   
   • revision: fe4f178db1ec9cd8cd14f91f2a68b7733638b573
   
   
   • path: deploy/aws/l4
   
   
   • namespace: test-ns
   
   
3. Refresh and sync this application.
4. Look at the resources in the test-ns and nginx-ingress namespaces: kubectl -n test-ns get all; kubectl -n ingress-nginx get all.

Resources have been deployed in ingress-nginx instead of test-ns.

Expected behavior

I expect Argo CD to enforce the destination namespace by overriding namespace in manifests resources or at least to fail with an error indicating the namespace contradiction (like kubectl does).

Version

argocd: v1.2.0+674978c
  BuildDate: 2019-09-04T21:26:04Z
  GitCommit: 674978cd587701b39e81fce6d5c960b6d76d5882
  GitTreeState: clean
  GoVersion: go1.12.6
  Compiler: gc
  Platform: linux/amd64
argocd-server: v1.2.0+674978c
  BuildDate: 2019-09-04T21:27:17Z
  GitCommit: 674978cd587701b39e81fce6d5c960b6d76d5882
  GitTreeState: clean
  GoVersion: go1.12.6
  Compiler: gc
  Platform: linux/amd64
  Ksonnet Version: 0.13.1

Have you thought about contributing a fix yourself?

Yes, but I think the direction to go should be discussed first (notably deciding if the namespace should be enforced or if an error should be raised).

[alexmt]

Hello @yann-soubeyrand, this is intended behavior. Argo CD honors namespace specified in the resource to unblock deployment of complex applications, such as the prometheus-operator, where all resources are supposed to be deployed into application namespace and few resources are deployed into hard-coded namespace.

This behavior is not documented well and mentioned only in https://blog.argoproj.io/argo-cd-v0-11-released-4c61ba669e67 , this has to be improved.

[alexmt]

Probably documentation is not enough. In most cases, all application resources must be installed into application namespace. If resource manifest in git has namespace then it might cause confusion. I think, In addition to documentation, we need an explicit application-level setting which enables/disables hardcoded resource namespaces.

@yann-soubeyrand , what do you think?

[yann-soubeyrand]

Fair enough, I didn't think about these use cases ;-)
Per application settings would do the trick I guess.

[alexec]

@yann-soubeyrand is your question answered please? Can we close?

[yann-soubeyrand]

@alexec yes, thanks!

[neilharris123]

Probably documentation is not enough. In most cases, all application resources must be installed into application namespace. If resource manifest in git has namespace then it might cause confusion. I think, In addition to documentation, we need an explicit application-level setting which enables/disables hardcoded resource namespaces.

@yann-soubeyrand , what do you think?

Hello @alexec @yann-soubeyrand Is there any plans to implement this? I too need a method of ensuring all resources are deployed into the application namespace in certain situations.

[yann-soubeyrand]

Hello @neilharris123, there is no plan on my side yet since project level constraint is enough for me at the time.

[KarstenSiemer]

do you know a way to change the namespace inside the e.g kustomize manifest to match the destination namespace set in the argocd application?
We are automatically deploying git pull request into our Kubernetes cluster using argocd to test them and trigger an git check to either block or allow a merge on a pr whether or not the deployed argocd application was able to become healthy.
For this to correctly work we need to create a new namespace for isolation and need to make sure that the entire application goes into that namespace.

e.g we have an app named myApp in a namespace named myNamespace.
Someone creates a PR with the destination branch of that app.
Then our pipeline comes by and creates a new app e.g myApp-pr-12.
This new app now has the target branch of the pr and needs to deploy into the namespace myNamespace-pr-12.

I got everything going except the application actually deploying into the pr namespace.
If I deploy the namespace itself with the app I maybe could get it to work using a kustomize nameRef.
But I'd like to enforce it on a higher level than the app itself.

Any ideas @yann-soubeyrand @alexmt ?

[jannfis]

@KarstenSiemer Since your CI already creates an ArgoCD application, how about it could also create a corresponding AppProject with a namespace constraint, and use that project when creating and applying the ArgoCD Application resource?

This would ensure that none of the resource can be installed in another namespace than the one allowed in the project. Syncing resources that specify another namespace in their manifests would fail. The resources to be synced should simply specify no namespace at all, so ArgoCD would automatically set it to the target namespace defined in the application.

But I agree that an application-level toggle allowOverrideNamespace: true|false (defaults to true) would be a good feature to have.

[KarstenSiemer]

@jannfis thanks for the advise!
Sounds like a great plan, didn't think of simply not specifying a namespace yet!