Why a tenant that can deploy into argocd is effectively Argo CD admin
Picture a platform team running one Argo CD instance for several tenant teams. Each team has an AppProject that controls what it can deploy and where. If one of those projects is allowed to create or modify resources in the argocd namespace, that tenant can reach admin-level control of the whole installation. The Argo CD cluster bootstrapping guidance says so directly: projects with access to the Argo CD namespace effectively have admin-level privileges. The reason is that the namespace holds the objects that define Argo CD's own behavior, including the Application and AppProject resources of every other team, the repository and credential Secrets, and the ConfigMaps that hold settings such as admin.enabled. Write access to those objects is write access to everything Argo CD manages.
Teams need these boundaries whenever more than one party can change what Argo CD deploys. That includes shared clusters where tenant workloads run next to the platform, multi-team installs where a central group owns the controller, and environments under formal change control, where a tenant should not be able to alter the access model that auditors rely on. If your organization fits any of these, review every AppProject and confirm for each one whether its destination list or resource allow list includes the argocd namespace or any cluster-scoped resource that could change Argo CD's configuration. Confirm also which identities can create Applications and where they are allowed to live, since those decisions determine whether a tenant can point an Application at the control plane.
The sections that follow cover the specific rules that close these paths: how sourceNamespaces should be limited, who may read the app of apps repository, and which cluster resources a project may deploy. Treat the namespace boundary as the first control to verify, because the other controls assume that tenants cannot write into the platform's own namespace. The cluster bootstrapping guide is the natural starting point for the reasoning behind this boundary.
How a tenant application could reach the argocd namespace
Argo CD's control plane lives in the argocd namespace, so anything that lets a tenant deploy there, or define Applications that point there, is a path to admin. The four paths below are the ones to close before tenants share a cluster with Argo CD.
Destination targeting the argocd namespace
An Application's destination can name the argocd namespace on the cluster where Argo CD runs. If a project allows that destination, a tenant's manifests can create or overwrite objects that Argo CD itself depends on, such as its ConfigMaps, Secrets and Deployments. Check every project's destination list and confirm that no tenant project matches the argocd namespace, including through wildcards.
Sourcenamespaces grants to argocd
The sourceNamespaces setting lets Applications be created in namespaces other than argocd. Granting a tenant project access to the argocd namespace this way lets that tenant create Application objects next to the platform's own configuration. The guidance is never to grant access to the argocd namespace through sourceNamespaces, so review every sourceNamespaces entry and remove any that name argocd.
App of apps repository access
In an app of apps pattern, a parent Application reads a Git repository that defines child Applications. Whoever can commit to that repository can therefore create new Applications, and those may target destinations the tenant could not reach directly. Confirm which repositories each project may read, who can merge to the parent repository, and whether child Applications are restricted to the tenant's own destinations.
Cluster-scoped resources a tenant can create
Cluster-scoped kinds such as ClusterRole, ClusterRoleBinding, CustomResourceDefinition and Namespace sit outside any single tenant namespace. If a project's cluster resource allow list includes them, a tenant can grant itself broader rights on the cluster, including rights over the argocd namespace. Keep the allow list minimal for tenant projects, and treat any cluster-scoped kind added to it as a privilege change that needs review.
Why sourceNamespaces must never include argocd
Never add the argocd namespace to a project's sourceNamespaces list. The Applications in any namespace guide says so directly, and the reason is that sourceNamespaces decides where a team may create Application objects that Argo CD will act on. An Application created in argocd is a control object: it can point at any repository the project allows and deploy into any destination the project allows, and the team that owns it can also edit the objects Argo CD itself reads. Granting a tenant project write access to that namespace therefore gives the tenant the same reach as the administrators who set up Argo CD, even if the tenant never touches the UI or the admin account.
Keep tenant namespaces explicit. List each team namespace by name in sourceNamespaces on the AppProject that team uses, and avoid wildcards or broad patterns that would silently pick up a namespace later created for another purpose. Pair this with the project's destinations and sourceRepos fields, because a project only creates Applications where its own rules allow. Review the list whenever a namespace is added, and treat a change to sourceNamespaces as a change to access control that goes through the same review as an RBAC change. Confirm in the version you run how the controller matches namespace patterns, since matching behavior has changed between releases.
Before relying on this control, confirm three things in your environment: which namespaces appear in each project's sourceNamespaces, whether any Application already exists in argocd from a tenant project, and whether the Argo CD release you run documents the same sourceNamespaces behavior in its own applications in any namespace guide. Check the current upgrade notes for your target version before you assume the default enablement or matching rules are unchanged.
Which boundary to use for each tenant model
This table compares four ways to keep tenant applications away from the argocd namespace, from per-project destination rules to separate Argo CD instances. Read each row against your tenant model: the more the boundary depends on Argo CD's own control plane, the more it needs the platform team to own the guardrails.
| Boundary | When it fits | What it protects | What it does not protect |
|---|---|---|---|
| Project destinations that exclude the argocd namespace | Shared Argo CD where teams deploy to their own namespaces on the same cluster | Stops a tenant Application from writing resources into the argocd namespace, including Secrets and Deployments that run Argo CD itself | Does not stop a tenant from deploying cluster-scoped resources unless cluster resource allow lists also restrict them |
| sourceNamespaces limited to tenant namespaces | Tenants that define their own Application resources in their own namespaces | Keeps Application objects outside the argocd namespace and limits which namespaces a project can read Applications from | Does not control where the Application deploys, so it must be paired with destination rules; never grant the argocd namespace here |
| Cluster resource allow lists per project | Projects that might request ClusterRoles, CRDs or Namespaces | Blocks cluster-scoped kinds that could grant admin rights or create namespaces the tenant should not touch | Does not limit namespaced resources, and an allowed cluster kind can still be used to widen access if broadly granted |
| Separate Argo CD instance per tenant | Tenants that need hard isolation, their own admin rights or different upgrade windows | Places each control plane, its Secrets and its RBAC in a separate trust domain, so one tenant cannot reach another's Argo CD | Does not remove the cost of running several installs, and each one still needs its own SSO, patching and backups |
| App of apps repository owned by the platform team | Platform teams that generate Applications for tenants from one parent repository | Keeps the source of tenant Application definitions under platform review rather than in tenant repositories | Does not stop tenants from writing Applications if they can still push to the parent repository or its referenced paths |
Setting up project boundaries that keep tenants out of argocd
This sequence removes every tenant path into the argocd namespace, from project destinations and sourceNamespaces to the app of apps repository and cluster-scoped resources, and ends with test Applications that prove a tenant cannot deploy there.
Inventory which projects reach which namespaces
The platform team lists every AppProject and records its destinations (server and namespace patterns), its sourceNamespaces, its source repositories and the clusters it can reach. Anyone who owns an Argo CD project with a destination that matches argocd, or with sourceNamespaces that include argocd, is a potential path to admin. Wildcards such as an asterisk in the namespace field need particular attention because they match argocd without naming it. Export the current state with the Kubernetes CLI so the review is based on what the cluster holds, not on what the team remembers. The step is done when the team has a written table of project, destination, sourceNamespaces and repository for every project, and each row has an owner. Confirm the exact behavior of wildcard matching against the version you run before you rely on it.
Remove argocd from destinations and sourceNamespaces
Edit each tenant AppProject so that no destination points at the argocd namespace and no sourceNamespaces entry names argocd. Tenant projects should target only their own namespaces. Where a team needs Applications defined outside its namespace, the Applications in any namespace feature is the supported mechanism, and it should be scoped to tenant namespaces only. The Argo CD documentation says never to grant access to the argocd namespace through sourceNamespaces, so treat any such entry as a defect to remove. Apply the change through Git so the edit is reviewed and recorded. The check is a fresh export of all AppProject objects, searched for argocd in destinations and sourceNamespaces, with zero matches in tenant projects. Keep a copy of the export as evidence for the change.
Restrict the app of apps repository to platform paths
An app of apps pattern lets one Application create other Applications from a repository. If a tenant can point an Application at that repository, or can change files under the paths it reads, the tenant can create Applications that target argocd. Restrict the repository to a platform-owned project, and in that project allow only the platform paths that hold Application manifests. Remove tenant access to the repository in the Git host, and require review for changes to those paths. Check the project's source list and the Git host permissions separately, because either one alone can leave a gap. The check is a test in which a tenant credential attempts to push a manifest under the platform path and the Git host rejects it, plus a review of the project source configuration showing only the platform repository and paths.
Set cluster resource allow lists for cluster-scoped kinds
Namespace boundaries do not cover cluster-scoped objects such as ClusterRoleBindings, CustomResourceDefinitions and namespaces themselves. In each tenant AppProject, set the cluster resource allow list to the small set of cluster-scoped kinds that the tenant truly needs, and leave out anything that can grant permissions or create namespaces. Likewise, use the namespace resource deny list for kinds that should never be created in tenant namespaces. Confirm which kinds your applications use by reviewing their manifests, since a deny-all default is easier to defend than an allow list built from memory. The step is complete when each tenant project's allow list has been reviewed by the platform team, and a dry run of a manifest containing a ClusterRoleBinding in a tenant project shows it is rejected by the project. Record the reviewed list alongside the project definition.
Test that tenants cannot create Applications in argocd
Verify the boundary with test Applications, not only by reading the configuration. Create a non-production tenant identity that holds only the tenant project role, then attempt to create an Application whose destination namespace is argocd, one that uses a sourceNamespaces entry naming argocd, and one that tries a cluster-scoped kind outside the allow list. Each attempt should be rejected by the API server or by Argo CD. Also confirm that the tenant identity cannot edit AppProjects or repository Secrets. Run the same tests after any change to projects, RBAC or the app of apps repository, and schedule them as part of the change process. The step is done when every attempt is rejected and the results are saved with the date, the Argo CD version tested and the identity used. Confirm the exact error messages against your version before writing them into test scripts.
Controls that keep the boundary intact over time
A boundary that holds at install can drift as teams add projects, repositories and clusters. The cards below are the controls that keep tenant applications from reaching the argocd namespace over time, and each one needs an owner and a recurring check.
Restrict who edits AppProjects
An AppProject sets which repositories, destination clusters, namespaces and resource kinds a project may use. If a tenant can edit its own AppProject, it can widen its own permissions, so AppProject objects should be writable only by the platform team. Check who holds update and patch on appprojects in Kubernetes RBAC and in Argo CD's own policy, and confirm that tenant pipelines cannot apply AppProject manifests from their repositories.
Scope Application write access per project
Argo CD's RBAC rules can match on project, so a role granted for one team should not grant write on Applications in another team's project. Review the p, policy lines for wildcards in the project field, since a wildcard quietly extends a role across every tenant. Remember that update and delete on an Application apply to the Application itself, so a role must be scoped to the right object names as well as the right project.
Review changes to the app of apps repository
An app of apps root repository defines Applications that create other Applications, so a change to it can add a destination or a source that no tenant reviewed. Require code review and protected branches on that repository, and restrict who can merge. Confirm that any project allowed to read it is trusted, because the repo-server will render whatever that repository contains, including Helm and Kustomize content from untrusted sources.
Monitor for new destinations
Every new cluster, namespace or server URL added to a project's destinations widens its reach. Alert on changes to AppProject destinations and on Applications that target the namespace argocd, and compare them with the approved registry of clusters. Ask the platform team which events reach a central log, and whether anyone reviews them within a set time.
Treat Git write access as cluster admin
In a GitOps model, whoever can push to a repository that Argo CD syncs can change what runs in the cluster. A commit that adds a privileged Application or a ClusterRoleBinding can reach the argocd namespace even if no one touches the cluster directly. Apply branch protection, signed commits and required reviewers to every repository in the sync path, and keep the list of people with write access short and current.
Questions teams ask before fixing tenant boundaries
How much effort does a tenant boundary review take?
The effort depends mainly on how many Argo CD projects, Git repositories and destination clusters your tenants can reach, and on how many of those projects already point at the argocd namespace or use sourceNamespaces. A small installation with one cluster and a handful of projects is a short review. Each additional project, repository and cluster adds rules to read, test and document. No effort figure is set here because it depends on your environment, so ask any partner to base the quote on a written inventory of projects, sources and destinations.
What does the work need from our platform and security teams?
The work needs people who can export the current Argo CD state and explain who owns each project. Your platform team should provide access to the Argo CD API or CLI, the Application and AppProject definitions, and the cluster list with the RBAC that grants access to the argocd namespace. Your security team should confirm which tenants are trusted, which repositories they may use and who approves changes to projects. Plan for these people to answer questions during the review, since many boundary problems are ownership questions rather than configuration questions.
Can our own team fix tenant boundaries in-house?
Often yes, if the team knows Argo CD projects, Kubernetes RBAC and the Argo CD application model well enough to read every project for dangerous destinations. The guidance is direct: projects with access to the argocd namespace effectively have admin privileges, and sourceNamespaces should never grant access to that namespace. Teams that choose to do this in-house should write a review checklist, verify each project against it, and keep the checklist under change control so later projects are reviewed too. A partner adds value mainly when the inventory is large or when an independent reviewer is needed for evidence.
How do we test that a tenant cannot escalate to Argo CD admin?
Test from the tenant's point of view, using a test account that holds only the tenant's project role. Attempt to create an Application that targets the argocd namespace, to add a sourceNamespaces entry naming argocd, to deploy a resource into argocd, and to point an Application at a repository or path that holds Argo CD configuration. Each attempt should fail, and the failure should be recorded. Repeat these checks after every project change, because a single permissive destination or source can reopen the path. Confirm your own test steps against the current Argo CD documentation for your version.
Which app of apps repository settings can let a tenant reach Argo CD configuration?
The risk comes from any repository a tenant can use as a source, especially a parent repository that generates child Applications. If a tenant can write to that repository, or can add a source that contains Argo CD Application or AppProject manifests, the tenant can define new Applications that the controller then processes. Review which repositories each project allows, restrict write access to the repositories that hold Argo CD configuration, and keep those repositories out of tenant source lists. Ask for a list of every repository reachable from each project during the review.
What does a boundary engagement deliver?
A typical written deliverable includes an inventory of projects, sources and destinations, a finding for each path that reaches the argocd namespace or grants cluster-scoped privileges, corrected project definitions or a change plan for them, cluster resource allow lists that match the intended scope, and a test script with recorded results. It should also name owners for each project and state how the controls are reviewed after changes. The exact list is set in the written scope before work starts, so ask for a sample deliverable when you request a quote.
Do cluster resource allow lists replace the other boundary controls?
No. An allow list limits which cluster-scoped kinds a project may create, which reduces what a tenant can do with cluster privileges, but it does not stop a tenant from targeting the argocd namespace. Destination rules, sourceNamespaces settings and repository restrictions each close a different path, so the review should check all of them together. Treat the allow list as one layer of a set of project controls that must be tested as a whole.
How DeployOpen scopes and delivers this hardening work
DeployOpen treats protecting the argocd namespace from tenant applications as a written, fixed-scope piece of work on an Argo CD instance you run in your own clusters. We start from your project inventory and the access each tenant actually has, then agree the controls, tests and documentation before any change is made.
How we scope
- Inventory every Argo CD project and map which destinations and namespaces each one can deploy into.
- Identify any project that can reach the argocd namespace and document why it effectively holds admin-level access.
- Agree in writing which sourceNamespaces, repository and cluster resource rules will change, and which stay as they are.
How we build
- Restrict project destinations, source repositories and cluster-scoped resource allow lists to the boundaries agreed in scope.
- Separate the app of apps repository so tenant teams cannot add or edit Application objects that point at protected namespaces.
- Test each boundary with attempted tenant deployments into argocd, and record the expected denials alongside the results.
How we hand over
- Deliver the project manifests, RBAC mapping and allow list configuration as version-controlled files with a change log.
- Write a runbook explaining how a platform owner reviews a new tenant request and what changes require a new review.
- Walk your platform and security teams through the test cases so they can rerun them after future Argo CD upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial work.
- Retest project boundaries when new tenants, clusters or Argo CD minor versions are introduced, as agreed in scope.
- Confirm with your team which Argo CD version and upgrade notes apply to your installation before any boundary change.
