Argo CD applications in any namespace

Argo CD applications in any namespace: what it changes for team self-service

Platform teams that want application owners to manage their own Applications without handing them access to the argocd namespace should know that Argo CD can now read Application resources from other namespaces. The feature, introduced in Argo CD 2.5, lets a team create an Application in a namespace it owns, while the Argo CD control plane stays where the platform team manages it. According to the Argo CD documentation, it requires a cluster-wide installation, so the API server and application controller can watch namespaces beyond argocd. A namespace-scoped install cannot use it. Enable it by setting application.namespaces in argocd-cmd-params-cm (or passing --application-namespaces) on both components, then confirm the exact configuration against the Applications in any namespace guide for your version.

Keep Applications in argocd when the platform team owns every deployment, when there are few teams, or when your cluster is namespace-scoped. Move to self-service when application teams deploy frequently, when a central queue for Application changes becomes the bottleneck, or when you already run projects and RBAC per team and want the Application object itself to live beside the workload it deploys. The core trade-off is that every Application you let teams create is a new unit of deployment power. A team that controls its Application can point it at repositories, destinations and sync behavior, so the project it belongs to becomes the real security boundary.

Self-service works only if the platform team decides, in advance, which namespaces may host Applications and which projects they may use. Each AppProject has to list the permitted namespaces in .spec.sourceNamespaces, and RBAC rules are written against the <project>/<namespace>/<application> form. Before rollout, agree on namespace ownership, confirm who can edit a project, and decide whether teams may change their own sync policies or only deploy within limits you set. Expect extra review effort at the start, as the platform team writes project and RBAC rules per team, and a recurring cost to keep them current as teams and clusters change. A partner can help design that model and test it, but the decisions about who may deploy where stay with your organization.

Argo CD application namespace settings and when each fits

This table compares the four configuration points that control application namespaces: the server-side setting, the project allow list, the RBAC naming form and resource tracking. Read each row for what it controls, when it fits your setup and what to confirm before you rely on it. The main takeaway is that the server setting alone does not grant anyone anything; each project must also allow the namespace.

Setting	What it controls	When it fits	What to confirm before using it
application.namespaces (argocd-cmd-params-cm) or --application-namespaces	Lets the API server and application controller watch Application resources in listed namespaces besides argocd. Introduced in Argo CD 2.5 and requires a cluster-wide installation.	Teams need to create Applications in their own namespaces and you run one cluster-wide Argo CD instance.	Confirm your install is cluster-wide, the exact namespace patterns you list, and that both the API server and application controller pick up the change.
spec.sourceNamespaces on each AppProject	Declares which namespaces may hold Applications that belong to that project.	Each team has its own project and a fixed, known set of namespaces to allow.	Confirm the list excludes argocd and that no user-controlled namespace is added to a privileged project such as default.
RBAC form <project>/<namespace>/<application>	Names an Application uniquely in RBAC rules so that policies can target one team's app in one namespace.	You write per-team policies and need to separate same-named applications in different namespaces.	Confirm your policy rules use the full three-part name and test them with a non-admin account before rollout.
Annotation-based resource tracking	Records ownership of managed resources in annotations rather than labels, so long composite names are not cut off by the 63-character label limit.	Application names combined with project and namespace can exceed the label limit, and you want reliable tracking across teams.	Confirm the tracking method on your installation and that existing resources migrate cleanly if you change it. Annotation tracking is the default from Argo CD 2.14 to 3.0.

Who configures what: platform team, project owners and application teams

The platform team owns the installation and the switches that make applications in any namespace possible at all. Because this feature only works in a cluster-wide installation, the platform team decides how Argo CD is deployed and which namespaces it watches. They also set the cluster-level defaults that every project inherits, so a mistake here affects every team on the instance.

Cluster-wide installation: Confirm Argo CD runs cluster-wide, since the feature requires it.
Enabling the setting: Set application.namespaces in argocd-cmd-params-cm (or pass --application-namespaces) on both the API server and the application controller.
Default project lockdown: Keep the default project free of user-controlled namespaces and do not grant it broad destinations.
Namespace ownership: Decide who creates team namespaces and never grant the argocd namespace to any project through sourceNamespaces.
Upgrade rules: Under the 2.14 to 3.0 change, update and delete RBAC applies only to the Application itself, and logs access needs an explicit logs, get permission. Review your RBAC policies against this before upgrading.

Ask the platform team to document the exact parameter values and namespaces in version control so changes are reviewed like any other configuration.

Project owners decide what each team's AppProject may do. In this model, the AppProject is the boundary: it lists the namespaces where Applications may live in .spec.sourceNamespaces, the source repositories and destination clusters the Applications may use, and the RBAC rules that govern who can act on them. Owners should keep these lists narrow, because every namespace listed becomes a place where a team can define Applications.

Source namespaces: List only the team namespaces that the project is meant to govern in .spec.sourceNamespaces.
RBAC rules per project: Write rules in the form <project>/<namespace>/<application> so that permissions match the namespace an Application actually lives in.
Repository and destination limits: Restrict allowed source repositories and destination clusters and namespaces to what the team needs.
Privileged projects: Keep user-controlled namespaces out of privileged projects such as default.
Review cadence: Re-check namespace lists whenever a team is created, renamed or retired.

Confirm that each project has a named owner and that the owner can show which namespaces and RBAC rules apply to it.

Application teams create and manage Application resources in the namespace they were given. Their freedom is real but bounded: they can define what their own Applications deploy and watch their sync state, but they cannot widen the project they belong to. Teams should understand the boundary so they know which requests go to the platform team or the project owner rather than being worked around.

What teams can do: Create, update and delete Applications in their own namespace, within the project's rules.
What teams cannot do: Add namespaces to a project, change project destinations or repositories, or act on Applications outside their namespace.
Logs access: Viewing logs requires an explicit logs, get permission after the 2.14 to 3.0 change, so teams should request it if they need it.
Naming: Use Application names that are unique across the instance, because the RBAC name combines project, namespace and application.
Requests: Send changes to projects or namespaces through the owner rather than editing shared resources.

Teams should confirm with their project owner which actions their role allows before relying on them in production.

Setting up Argo CD applications in any namespace, step by step

This sequence moves a cluster-wide Argo CD install from the default argocd-only model to one where each team creates and manages its own Application resources in a namespace it owns, with project and RBAC boundaries that limit what each team can deploy and where.

Confirm a cluster-wide Argo CD installation
The platform team checks that Argo CD runs as a cluster-wide installation, not a namespace-scoped one, because applications in any namespace depend on the API server and application controller watching namespaces beyond argocd. Confirm the installed version supports the feature (it was introduced in Argo CD 2.5) and record the version in your change ticket. Verification: the API server and application controller pods run with cluster-scoped permissions, and listing namespaces through the Argo CD service account returns more than the argocd namespace.
Enable application namespaces on the control plane
Set the list of namespaces Argo CD may read Applications from by configuring application.namespaces in the argocd-cmd-params-cm ConfigMap, or by passing the --application-namespaces flag to the API server and application controller. Restart both components so they pick up the change. Keep the list to the team namespaces you have approved, not a wildcard. Verification: the API server logs show the namespaces it is watching, and a test Application created in an approved namespace appears in the Argo CD UI and CLI.
Create the team namespaces
Create one namespace per team or per application group, with labels and resource quotas set by your platform standards. Do not reuse the argocd namespace or a namespace that already runs privileged workloads. Name namespaces so that the namespace is clearly tied to one owning team, because the namespace becomes part of the RBAC subject later. Verification: each namespace exists, carries the expected labels, and is listed in the approved set from the previous step.
Add sourceNamespaces to dedicated AppProjects
Create a dedicated AppProject for each team and list its permitted team namespace under .spec.sourceNamespaces, along with the source repositories and destination clusters and namespaces that team may use. Do not add user-controlled namespaces to the default project or any project with broad destinations, and never list the argocd namespace in sourceNamespaces. Verification: an Application created in the team namespace that points to the team's project is accepted, and an Application in the same namespace that points to a different team's project is rejected with a permission error.
Write RBAC rules using the project, namespace and application form
Write RBAC policy entries that reference applications with the <project>/<namespace>/<application> form, so a rule for one team's application does not match another team's application with the same name. Grant update and delete rights only where a team needs them, and grant logs access with an explicit logs, get permission if teams need pod logs. Bind these rules to groups from your identity provider rather than individual users. Verification: sign in as a test user from one team, confirm they can sync their own application, and confirm they cannot view or sync an application in another team's namespace.
Switch to annotation-based resource tracking
Set the resource tracking method to annotation-based, which is the default in Argo CD 3.0 and later, and is strongly recommended for this model. Composite names made from project, namespace and application can exceed the 63-character limit for labels, so label-based tracking can fail for longer names. Apply the change to existing applications through a planned resync, and confirm with your team how the change will look in their sync history before it runs in production. Verification: resources created by an application carry the tracking annotation, and applications with long composite names show a healthy sync status.
Test with a sample Application and a denied project
Deploy a small, non-sensitive sample Application (for example, a single ConfigMap in a test repository) from a team namespace through the team's project. Then attempt the same deployment through a project that does not list that namespace, and through the argocd namespace, to confirm each attempt is refused. Record the results with the RBAC version and the project definitions so auditors can trace the boundary later. Verification: the permitted deployment syncs, and each denied attempt fails with a visible error in the Argo CD UI or CLI.

Security controls that keep team namespaces from widening access

Letting teams create Applications outside the argocd namespace moves trust boundaries into AppProjects, RBAC and the repositories teams can point at. The cards below cover the controls that keep one team's Application from reaching another team's namespace, cluster or credentials.

Keep argocd out of sourceNamespaces

Every AppProject lists the namespaces its Applications may live in under spec.sourceNamespaces. Adding the argocd namespace there lets any project member create Applications beside the control plane's own objects, which is the broadest widening available in this feature. Review each project's list during onboarding and treat any change to it as a platform change that needs review. Confirm that no project in your cluster includes argocd through a periodic check of the project manifests.

Keep user namespaces out of privileged projects

The default project is open unless someone restricts it, so an Application created in a team namespace and assigned to default inherits broad destinations and source access. Keep team namespaces out of sourceNamespaces on default and any other project that holds cluster-wide permissions. Give each team its own project with explicit destinations, allowed source repositories and namespace lists. Check that no team-facing namespace appears in a privileged project during each access review.

Scope RBAC to project, namespace and application

RBAC rules for namespaced Applications use the form <project>/<namespace>/<application>, so a policy written against only the project name can match more than intended. Write each rule with the full three-part name, and avoid wildcards that span namespaces owned by different teams. Pair this with the 3.0 change that makes update and delete apply only to the Application itself, and grant logs, get explicitly where teams need pod logs. Test each rule with a second team's Application before you rely on it.

Rely on JWT-only API access and redaction

Argo CD authenticates API requests only with JSON Web Tokens and redacts cluster, Git and OAuth2 credentials from API responses and logs. These protections hold for teams as well as platform admins, so a self-service user cannot read repository or cluster secrets through the API. Still confirm that token lifetimes and SSO group mappings match your access policy, and that the built-in admin user is disabled with admin.enabled set to false. Check that no team has been given access to the Secrets that hold repository credentials.

Control what the repo-server can read

The repo-server runs Helm and Kustomize against repository content, so a team that points an Application at an untrusted repository can cause that tool execution. Out-of-tree file references in Kustomize or Helm values can also reach files outside the intended path. Restrict which repositories each project may use through its source list, and review Helm and Kustomize sources in new team repositories before the first sync. Ask your team to confirm whether the sources they choose are internal, reviewed and pinned to known revisions.

Use annotation tracking for team resources

Annotation-based resource tracking is the default from Argo CD 3.0 and is strongly recommended for namespaced Applications, because composite <namespace>_<application> names can exceed the 63-character label limit. Without it, two Applications in different namespaces can claim overlapping resources or prune each other's objects. Confirm the tracking method in argocd-cm before onboarding the first team, and test pruning in a non-production namespace so a team cannot remove a sibling's workloads.

The configuration mistakes that turn self-service into cluster-wide access

The most damaging errors in an any-namespace setup come from widening the project boundary rather than from the feature itself. The first is listing the argocd namespace in an AppProject's .spec.sourceNamespaces. That namespace holds the Argo CD control plane and its configuration, so a team permitted to create Applications there could change how Argo CD itself is configured, and any project that accepts it becomes a path to the control plane. The second is adding team namespaces to the default project. Every Application without an explicit project lands there, and if default also accepts applications from user-controlled namespaces, a team can place workloads under a project whose permissions were never meant for them. Review each AppProject's sourceNamespaces and destinations fields, confirm the argocd namespace is absent, and confirm that default allows only the namespaces you have deliberately placed there.

The third error is wildcard RBAC across projects. Argo CD RBAC rules take the form <project>/<namespace>/<application>, so a rule such as p, role:team-a, applications, *, */*, allow grants the role action on every application in every project and namespace the rule matches. A wildcard in the project or namespace segment lets one team's role read, sync or delete another team's Applications, which is the same cross-team effect as the namespace mistakes above but harder to see because it lives in a single policy line. Search the RBAC policy for * in the project and namespace positions, and check that each team's role names its own project and namespace explicitly. Remember that the 2.14 to 3.0 upgrade changed update and delete permissions to apply only to the Application itself, so confirm your rules match the version you run.

The fourth error is relying on name-based resource tracking. Argo CD composes names from the namespace and application name, and those composite names can exceed the 63-character label limit that name-based tracking depends on. When that happens, Argo CD can lose track of which resources an Application owns, and one team's sync or prune can touch resources that belong to another. The defense is annotation-based tracking, which is the default in Argo CD 3.0 and is strongly recommended for this feature. Confirm the application.resourceTrackingMethod setting in argocd-cm, and check existing installs that were upgraded from earlier releases, since the setting may not match the default you assume. Flag any Application whose namespace and name together are long enough to approach the limit, and include that check in the review of every new team onboarding.

Limits to confirm in your environment before rollout

Enabling Applications in any namespace changes who can create workloads and how Argo CD matches them to projects. The checks below cover the install model, the version you run, existing Applications, SSO, naming and controller capacity. Confirm each item against the official guide for your exact release before you change production settings.

Cluster-wide installation

The feature requires an installation that can watch namespaces beyond argocd, so a namespace-scoped install is not a fit. Confirm which namespaces your API server and application controller can see, and whether your cluster role bindings allow it. Check how the application.namespaces setting in argocd-cmd-params-cm is applied on both components, and confirm the change is in place on each before teams create Applications outside the argocd namespace.

Version and documented behavior

Confirm the Argo CD release you run and read the matching guide, since the feature and its RBAC behavior have changed across releases. Only the three most recent minor versions receive patch releases, so an older install may lack fixes. Check the release notes for your version before relying on the naming and matching rules in this guide.

Existing Applications and migration

Applications already in the argocd namespace stay where they are, but teams moving work into their own namespaces need a plan for each one. Confirm how an Application's namespace affects its tracking, ownership and deletion, and whether a move requires recreating the resource. Test the move on a non-production cluster and record which Applications change and which projects they belong to.

SSO group mapping

Group claims from your identity provider or Dex decide which people hold which project roles, so they now also decide who can create Applications in a namespace. Check how each group maps to a role and whether a broad group can reach a privileged project. Confirm the claim your SSO setup uses for RBAC, because the 3.0 upgrade changed how Dex-based RBAC reads user identity.

Team naming and RBAC matching

RBAC rules match on the form <project>/<namespace>/<application>, so a naming scheme that is ambiguous or changes over time breaks policies silently. Decide whether namespace names and Application names are unique and stable across teams. Test a sample policy against both a matching and a near-matching name before rollout, so a typo does not grant access to another team's Application.

Controller sharding and capacity

Each new namespace adds Applications for the controller to reconcile, and the destination clusters they target add further load. Check how many Applications and clusters the current controller handles, and whether sharding is configured for the controller replicas. Confirm the sharding approach for your Argo CD version with the high availability documentation before adding teams.

Questions teams ask before enabling Applications in any namespace

What does it cost to enable Applications in any namespace?

The cost is the partner's fixed-scope fee for the written work plus your internal time, and no public price list applies, so a quote follows from the agreed scope. The main drivers are the number of AppProjects you need, how many team namespaces must be permitted, whether SSO group mapping must change, and how many existing Applications have to move out of the argocd namespace. Ask the quote to separate one-time work (cluster-wide configuration, project model, RBAC, migration, verification) from recurring work (project onboarding, reviews of new namespaces, upgrades). Ask whether the work includes a runbook for adding a team later.

How long does a first rollout of Applications in any namespace take?

Duration depends on scope rather than on the feature itself. A pilot with one project, one team namespace and no SSO changes is much shorter than a rollout that covers several business units, existing Applications that need to be recreated, and new identity group mappings. The Argo CD upgrade path also matters: the feature requires a cluster-wide installation, so a rollout on an older or namespace-scoped install adds work first. Ask the partner for a timeline tied to named phases and a list of the assumptions behind it, and confirm which phases depend on your change approvals.

What do we need to provide before the work starts?

The work needs access and decisions from several owners before any configuration changes. Plan for:

Administrative access to the clusters where Argo CD runs, and read access to the Git repositories that hold Application definitions
An owner for the identity provider so SSO groups can be mapped to Argo CD roles
An agreed project model that states which teams own which AppProjects, which namespaces each project may use, and which projects are privileged
A named approver for changes to argocd-cmd-params-cm and to the RBAC policy

Without the project model, the namespace permissions cannot be written, so agree it early.

Can our internal platform team do this without a partner?

Yes, a team that already runs Argo CD and understands AppProjects, RBAC and cluster-wide installation can implement this feature alone. The feature itself is configuration: enabling application namespaces, listing permitted namespaces in each project's sourceNamespaces, and writing RBAC rules in the form project/namespace/application. The harder parts are design choices that carry security risk, such as keeping the argocd namespace and privileged projects out of team permissions. A partner is most useful when the team lacks time for the design review, needs an independent check of the permission model, or wants the work documented as evidence for change control.

What security mistakes make this feature risky?

The most serious mistake is granting the argocd namespace through sourceNamespaces, because it gives a project control over Applications that the control plane itself uses. Adding user-controlled namespaces to a privileged project such as default is the second. Teams should also remember that the repo-server runs Helm and Kustomize on repository content, so an untrusted repository reachable from a team project is a risk in its own right. Review every project's destinations, source repositories and namespace list together, and confirm that each team's permissions cannot widen through a shared RBAC group.

Why should we use annotation-based resource tracking with this feature?

Annotation-based tracking is strongly recommended because the composite names used for Applications in other namespaces can exceed the 63-character limit that Kubernetes places on label values. Argo CD 3.0 makes annotation tracking the default, so new installs usually already use it, but older configurations may still rely on labels. Check the tracking method on each cluster before the rollout, and test a team Application that uses a long name to confirm that its resources sync and report health as expected.

What ongoing work remains after the rollout?

The recurring work is governance and upkeep rather than new build. Each new team needs a reviewed AppProject entry, a namespace decision, and an RBAC review. Argo CD releases a minor version four times a year, and only the three most recent minor versions receive patch releases, so upgrades must be scheduled regularly and tested against the permission model. Ask for a regular access review of projects and namespaces, a documented offboarding step for teams that leave, and a retainer quote if you want ongoing support or upgrades handled externally.

How DeployOpen scopes, delivers and supports Argo CD namespace self-service

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Argo CD Applications in any namespace, we treat the namespace model as a governance decision first, then build the configuration, tests and handover around the boundaries your platform team agrees to.

How we scope

Written scope lists which teams get namespaces, which projects they may use and which namespaces each project permits.
We record the Argo CD version, cluster topology and installation mode, since namespace support depends on a cluster-wide install.
We confirm which privileged projects, such as default, stay closed to user-controlled namespaces and who approves exceptions.

How we build

We enable application.namespaces and sourceNamespaces on projects with only the namespaces agreed in the scope, never the argocd namespace.
We set RBAC rules in the <project>/<namespace>/<application> form and test allow and deny cases for each team role.
We configure annotation-based resource tracking and check that long composite application names work in your environment.

How we hand over

Handover includes a runbook for adding a team namespace, a project template and the RBAC and sourceNamespaces review checklist.
We document the test cases used to prove isolation, so your team can rerun them after upgrades or configuration changes.
Your engineers work through the build with us, so they can own team onboarding after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, covering Argo CD patch and minor releases as your scope requires.
Changes to projects, namespace permissions or RBAC go through the same review path as the original build.
Ask any implementation partner to confirm how they handle Argo CD upgrade notes that change RBAC or resource tracking behavior before you sign.

Argo CD applications in any namespace for team self-service