managedNamespaceMetadata clashing with clusterResourceWhitelist in AppProject?

[ben-foxmoore]

I'm trying to set up Argo with a separation of responsibilities - between "IT" that manage Argo itself via a Git repo containing AppProjects and ApplicationSets, and developers who manage their own app repos (containing Kustomize manifests in a deploy/ directory). The ApplicationSet discovers apps via a Git file generator and deploys each into its own namespace. The expectation was that we could use Argo's CreateNamespace option to create the Namespace for each app, which would allow our AppProject to forbid developers from creating Namespaces at all.

However it seems that when using the managedNamespaceMetadata option to attach some labels to the auto-created Namespace, it fails with:

resource :Namespace is not permitted in project external-apps

Looking at the source code in sync_namespace.go, when ManagedNamespaceMetadata is non-nil, ArgoCD adds the Namespace to the sync task list as a resource, which then gets checked against the AppProject's clusterResourceWhitelist.
Adding Namespace to clusterResourceWhitelist fixes the sync, but it defeats the purpose of our approach - developers could then include a namespace.yaml in their app manifests and create arbitrary namespaces with whatever labels they want.

1. Is there a way to allow managedNamespaceMetadata without opening up clusterResourceWhitelist to Namespace? It seems like the namespace metadata set by the ApplicationSet (which IT controls) should be treated differently from namespace resources in the app manifests (which developers control).
2. Has anyone found a workaround for this pattern? We considered using clusterResourceWhitelist with resourceNames to restrict which namespaces can be created, but the allowed names vary per-app and can't be templated in a shared AppProject.
3. Would it make sense to file a feature request for ArgoCD to bypass the AppProject check for the implicit namespace created by CreateNamespace=true + managedNamespaceMetadata, since it's controlled by the Application spec (not the app manifests)?

---

For reference, our external-apps AppProject is intentionally restrictive:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: external-apps
spec:
  sourceRepos:
    - 'https://github.com/our-org/*'
  destinations:
    - namespace: '*'
      server: https://kubernetes.default.svc
  clusterResourceWhitelist: []
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: 'Deployment'
    - group: ''
      kind: 'Service'
    - group: ''
      kind: 'ConfigMap'
    - group: ''
      kind: 'Secret'
    - group: 'networking.k8s.io'
      kind: 'Ingress'

and the syncPolicy:

syncPolicy:
  syncOptions:
    - CreateNamespace=true
  managedNamespaceMetadata:
    labels:
      app.kubernetes.io/managed-by: argocd

[sueun-dev]

You've identified a real architectural gap in ArgoCD — this is a known limitation tracked in issue #22869.

Why it happens

When managedNamespaceMetadata is non-nil, ArgoCD's sync engine adds the destination Namespace to the sync task list as a managed resource, which then goes through the normal AppProject authorization check against clusterResourceWhitelist. There's no mechanism today to say "this Namespace was created by the ArgoCD operator config, not by the developer's Git repo — treat it differently."

Workaround: separate AppProject for namespace management

The cleanest approach that fully preserves your intent is to split namespace lifecycle into its own AppProject:

1. Create a namespace-mgmt AppProject controlled by IT, with clusterResourceWhitelist allowing Namespace. The source repos are IT-only repos (not developer app repos).

2. Add an ApplicationSet in that project that creates the namespaces explicitly (a simple Kustomize overlay or even a raw Namespace manifest generator per team).

3. Remove CreateNamespace=true and managedNamespaceMetadata from the developer ApplicationSet. The namespaces are pre-created; apps just sync into them.

4. Keep external-apps AppProject with an empty clusterResourceWhitelist. Developers cannot include a Namespace resource in their app manifests and have it sync — it'll be blocked.

# namespace-mgmt AppProject (IT-managed)
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: namespace-mgmt
spec:
  sourceRepos:
    - 'https://github.com/our-org/platform-infra'  # IT repo only
  destinations:
    - namespace: '*'
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace

This fully separates the two concerns: IT controls namespace lifecycle (including labels), developers are physically blocked from touching cluster-scoped resources.

ArgoCD v3.3+ partial mitigation

If you're on ArgoCD v3.3+, PR #24674 added a name field (with glob support) to clusterResourceWhitelist. You can scope it to specific name patterns:

clusterResourceWhitelist:
  - group: ''
    kind: Namespace
    name: 'team-a-*'

This limits blast radius but doesn't fully solve your problem — a developer can still include a Namespace manifest in their repo matching the pattern and it'll sync through. So it's an incremental improvement, not a complete separation.

On filing a feature request

Yes, it's absolutely worth it. The exact feature that's been proposed (but not implemented) is an allowDestinationNamespaceCreation flag on AppProject that would let ArgoCD create/patch only the application's declared destination namespace without routing it through the clusterResourceWhitelist check. Issue #22869 was closed in favor of the name-based filtering (PR #24674), but that doesn't address the architectural gap you've described. A new issue referencing #22869 and #24674 as incomplete mitigations would be appropriate.

In the meantime, the separate AppProject approach is the most robust path forward.