Least-privilege access from Argo CD to clusters

Least-privilege access from Argo CD to managed clusters starts with what it can write

Argo CD needs read access cluster-wide on each managed cluster, but it does not necessarily need full write privileges everywhere. A platform team that registers several clusters in one Argo CD should treat the credential Argo CD holds on each destination as the first control to narrow, because it sets the ceiling for everything a sync can change. The Argo CD security documentation confirms that write access can be limited to specific namespaces and resources by editing the argocd-manager-role ClusterRole on external clusters, so the default broad grant is a choice you can revise rather than a fixed requirement.

This section covers three control points that work together. The first is the argocd-manager-role on each external cluster, which defines the verbs Argo CD can use. The second is the cluster resource allow list in each AppProject, which controls which cluster-scoped kinds an application may create even when the role would permit them. The third is sync impersonation per destination, which makes a sync run as a named service account in the target namespace instead of the cluster-level credential. Before changing the role, list the namespaces and kinds each team actually deploys, and confirm with your platform owner which cluster-scoped objects, such as CRDs, Namespaces and ClusterRoles, must still be managed by Argo CD.

You need this work when one Argo CD manages production and non-production clusters, or when several teams share a cluster and a single credential would let any project reach any namespace. It does not replace AppProject source and destination rules, which decide what each team may deploy, or the RBAC policy that decides who may sync. Narrowing the role also does not remove the need to lock down the default project, protect repository content from untrusted Helm and Kustomize input, or keep credentials in Secrets. Confirm the exact role contents and impersonation settings for your Argo CD version against the Argo CD security documentation before you change anything in production.

Which access model fits each managed cluster

This table compares four ways to limit what Argo CD can write on a managed cluster, showing what each option restricts, what it leaves open, and whether it suits a shared or dedicated cluster. Read each row as a layer: the options can be combined, but none of them replaces the others. The main takeaway is that a shared cluster needs namespace-scoped write and project-level resource allow lists together, while a dedicated cluster may accept a broader role if the team owns the whole cluster.

Access model	What it restricts	What it does not restrict	Fits shared or dedicated clusters
Default broad ClusterRole	Nothing beyond the cluster role Argo CD was registered with; it is the baseline	Cluster-scoped writes, cross-namespace writes and any resource kind, so a misconfigured app can change anything	Dedicated clusters where one platform team owns the whole cluster and accepts broad write
Cluster-wide read with namespace-scoped write (argocd-manager-role)	Write access to named namespaces and resources, by editing the argocd-manager-role ClusterRole on the external cluster	Read access stays cluster-wide, and rules you leave out of the role still need checking against what apps deploy	Shared clusters where each team gets its own namespaces; the usual starting point
Project cluster resource allow lists	Which cluster-scoped kinds (such as Namespace or ClusterRole) a project's applications may create	Namespaced resources in allowed namespaces, and it applies only to Argo CD syncs, not to kubectl access	Shared clusters where teams may create some cluster-scoped objects but not others
Sync impersonation per destination	The identity used for each sync, so the Kubernetes RBAC of that identity limits what Argo CD can apply	Anything the impersonated identity is allowed to do, and it requires that identity to be configured on the destination cluster	Shared clusters with several tenants that need separate Kubernetes identities; confirm the feature and version with the project documentation before design
Combined model (illustrative)	Namespace-scoped write, allow lists in each project and a per-team identity together	Compromise of the Argo CD server or a repository the team controls still matters, so repo and SSO controls remain needed	Shared clusters with regulated tenants; ask your team to confirm the configuration with a test sync before rollout

How project resource allow lists narrow what teams can deploy

An AppProject is the layer that decides what Argo CD will apply for a team, even when its service account could write more. The controls below work in parallel: each one narrows a different dimension of a deployment, and together they sit on top of the cluster-level write permissions described earlier.

Cluster resource allow lists

A project's cluster resource allow list names the cluster-scoped kinds, such as Namespace or ClusterRole, that its applications may create. An empty list blocks all cluster-scoped resources, which suits most team projects. Check that each allowed kind is one the team truly owns, because a permitted ClusterRole can grant rights far beyond the project.

Namespace resource allow and deny lists

Namespace-scoped allow and deny lists limit which kinds a team can deploy inside its namespaces, such as blocking ResourceQuota changes or NetworkPolicy edits. Deny rules take precedence, so a narrow allow list still needs explicit exclusions for sensitive kinds. Test the lists against a sample manifest set before handing the project to a team.

Destination restrictions

Destinations pair a target cluster with a namespace pattern, so a project can only sync into the namespaces it was given. Wildcard namespaces are convenient but widen the blast radius, and a shared cluster with many tenants needs exact names or tightly scoped patterns. Review destinations whenever a team adds a namespace.

Source repository limits

The sourceRepos list controls which Git repositories and Helm registries an application may pull from. Restricting it to the team's own repositories stops an application from pointing at an untrusted repository, which matters because the repo-server executes Helm and Kustomize on repository content. Confirm that no team can add repositories to its project without a platform review.

Project roles bound to SSO groups

Project roles grant sync and override rights inside one project, and they can be mapped to identity provider groups. Bind each role to a group the identity provider manages, and keep role membership out of local accounts. Verify that a removed group member loses sync rights in Argo CD on the next login, and that no broad group grants access to several projects.

Emptying the default project

The default project permits any repository, destination and resource kind, so an application created there bypasses every project boundary. Empty its sources and destinations so that each application must belong to a deliberately scoped project. Check this on every new install and after any upgrade, because a fresh instance still carries the permissive default.

Setting up narrowed write access for one managed cluster

This sequence takes one external cluster from a broad registration to a scoped one, where Argo CD reads cluster-wide, writes only where each team is allowed, and proves that out-of-scope writes are refused. The output is a tested cluster registration tied to AppProjects that match the team boundaries.

Inventory the kinds and namespaces each team deploys
The platform team works with each application team to list the namespaces, resource kinds (for example Deployments, Services, Ingresses, ConfigMaps and CRDs) and any cluster-scoped objects each team needs to create or update. Record the list per team in a short table kept in Git. Done means every team has a signed-off list, and any cluster-scoped kind is either justified in writing or marked as excluded. Ask each team to confirm the list against its current manifests so that nothing is missed on the first sync.
Define the argocd-manager-role rules
On the external cluster, the platform engineer edits the argocd-manager-role ClusterRole so that it keeps cluster-wide read access and grants write verbs only for the namespaces and resources from the inventory. Namespace-scoped grants use Role and RoleBinding objects in each target namespace where the scope is narrower than the whole cluster. Done means kubectl auth can-i --list run with the manager's service account shows read verbs cluster-wide and write verbs only in the approved namespaces. Confirm the exact rule structure against the current Argo CD security documentation before applying it.
Register the cluster with its scoped credential
The platform engineer registers the external cluster using the bearer token of the argocd-manager service account, either through the argocd CLI or as a declarative cluster Secret in the Argo CD namespace. The token must belong to the scoped service account, not to a cluster-admin kubeconfig. Done means the cluster appears in Argo CD with a Successful connection status, and the stored credential is no longer the one that existed before narrowing. Confirm the token lifetime and rotation method with your cluster distribution, since they differ by platform.
Create AppProjects with destination and resource allow lists
The platform team creates one AppProject per team with the team's source repositories, the approved cluster and namespace destinations, and a cluster resource allow list that contains only the cluster-scoped kinds approved in step one. Project roles are bound to the team's SSO group. Done means each project shows only its own repositories and destinations in the Argo CD UI, and the default project no longer permits any destination. Check the project manifests into Git so that changes go through review.
Configure sync impersonation for the destination
If your Argo CD version and setup support sync impersonation, the platform team configures each destination so that syncs run as a dedicated service account in the target namespace rather than as the manager account. The service account gets only the permissions that team needs, and the destination is set in the AppProject. Done means a sync from a team project runs under the expected identity, which you confirm in the sync operation details or the Kubernetes audit log. Treat this as optional, and confirm the feature state for your release with the official documentation before you rely on it.
Verify with a test application that out-of-scope writes are refused
Create a test application in one team project that deploys an allowed resource into an allowed namespace, then sync it. Next, add a manifest with a disallowed cluster-scoped kind and a second one targeting a namespace outside the project's destinations. Done when the allowed sync succeeds and both out-of-scope attempts are rejected, with the rejection visible in the application conditions or the Argo CD event log. Remove the test application afterward and keep the test manifests in the repository as regression checks for later changes.
Record the scope and schedule a permission review
The platform team writes down the final ClusterRole rules, project list, destinations and impersonation settings in the cluster's runbook, along with the owner of each team boundary. A recurring review of the inventory against actual manifests keeps the scope current when teams add kinds or namespaces. Done means the runbook is committed, the owners are named, and a review cadence is set by the organization. Ask your auditors or internal control owners which evidence they expect from this record.

Risks that remain after narrowing Argo CD write access

Narrowing write access on managed clusters closes some paths but leaves others open. The cards below cover the risks that stay in place after the manager role and project allow lists are tightened, and what to check for each one.

Untrusted repository content

The repo-server runs Helm and Kustomize on repository content to render manifests. A repository that is not trusted can influence what gets rendered, and out-of-tree file access is a risk to control. Narrow write access does not stop a malicious chart or overlay from requesting resources that the project permits. Check which repositories each AppProject can read, limit them to repositories your teams own, and review Helm and Kustomize inputs before they reach a sync. The repo-server exposure is the part to review first.

Admin access and default paths

The built-in admin user can bypass the project and RBAC model you have built. The user management documentation recommends using it only for initial setup and disabling it with admin.enabled set to false once local users or SSO are configured. Confirm that the admin account is disabled in every Argo CD instance, that break-glass access is documented, and that no default project still permits any repository and cluster.

SSO group mapping drift

Roles in Argo CD are often bound to identity provider groups, so a group that is broader than intended grants broader rights on every destination it maps to. Group membership changes in the identity provider take effect without any change in Git. In Argo CD 3.0, Dex-based RBAC uses the federated_claims.user_id claim, so confirm which claim each mapping relies on. Review group-to-role bindings on a fixed schedule and compare them with the team structure.

Credentials in cluster Secrets

Each managed cluster registration is stored as a Kubernetes Secret that holds the credentials Argo CD uses to reach that cluster. Anyone who can read those Secrets on the Argo CD cluster can use the credentials elsewhere, whatever the manager role allows. Restrict who can read Secrets in the Argo CD namespace, avoid long-lived static tokens where your cloud offers short-lived alternatives, and confirm that cluster credentials are redacted from API responses and logs as the security documentation describes.

Audit of project and role changes

Narrow permissions are only useful if changes to them are visible. Changes to AppProjects, cluster Secrets and RBAC policy can happen in Git, through the API or directly in the cluster, and each path leaves different evidence. Confirm that all changes flow through Git review, that direct edits to these objects are detected, and that your log pipeline captures Argo CD API and controller events. Check who can alter the Argo CD configuration itself, because a change there can widen every other control.

How the approach differs for shared and dedicated clusters

On a shared cluster, several teams run workloads side by side, so the main risk is one team's deployment touching another team's namespaces or cluster-scoped objects. Plan the write scope around tenant namespaces only. The cluster-wide part of the grant should stay read-only so Argo CD can discover resources, while writes are limited to the namespaces each tenant's project may deploy into.

Write scope: Namespace-scoped write for each tenant, bound through a dedicated ClusterRole or Role per tenant instead of one shared grant.
Namespaces and kinds: Workload kinds such as Deployments, Services and ConfigMaps inside tenant namespaces. Exclude cluster-scoped kinds such as CustomResourceDefinitions, ClusterRoles and Namespaces unless a platform owner approves them.
Cluster resource allow lists: Keep the cluster resource allow list in each AppProject empty or minimal, so tenants cannot request cluster-scoped objects through their own applications.
Shared infrastructure: Treat admission policies, network policies and quotas as platform-owned, and confirm that no tenant project can reference them.
Impersonation: Confirm whether sync impersonation is in use for each tenant destination, so a sync runs with that tenant's identity rather than the controller's.

Before rollout, confirm with each tenant owner which namespaces and kinds their applications actually need, and test that a deliberately out-of-scope resource is rejected.

Questions teams ask before narrowing Argo CD cluster access

What drives the effort of scoping Argo CD roles and allow lists?

The effort follows the number of clusters, the number of namespaces each team deploys into, and how many resource kinds the workloads use. Each managed cluster needs its own review of the argocd-manager-role, because Argo CD needs read access cluster-wide but not necessarily full write privileges. Teams that use custom resource definitions, operators or cluster-scoped objects such as CRDs, webhooks and storage classes spend the most time, since each kind must be either allowed or deliberately excluded. Ask for the inventory of clusters and resource kinds to be part of the written scope, because that inventory sets the work.

What does the work need from our cluster and Argo CD administrators?

It needs both teams early. Cluster administrators confirm which namespaces each workload owns, which cluster-scoped resources are truly required, and who may approve changes to the ClusterRole on each external cluster. Argo CD administrators confirm the AppProject definitions, which repositories each team may use, and how SSO groups map to project roles. Expect to provide access to a non-production cluster for trial syncs, and a named owner for sign-off. If either group is unavailable, the scope stalls because every allow list is a decision about someone else's workloads.

Can our team narrow Argo CD access without outside help?

Yes, many platform teams do this in-house, especially with a small number of clusters and a stable set of resource kinds. The work is mostly careful reading of the existing manifests, testing in a non-production environment and documenting the result. Outside help is most useful when the team lacks time to test every application against the narrower rules, or when it needs an independent review of the final roles before a change window. Whichever path you choose, the written scope should list who performs each task and who signs off.

How long does this take as cluster count and resource kinds grow?

Duration grows with the number of clusters and with the variety of resource kinds per cluster, not with the number of applications alone. A few clusters with a standard set of workload types usually take less time than many clusters with custom resources and several teams sharing namespaces. Ask any provider to split the estimate into discovery, rule design, testing per cluster and rollout, and to state which assumptions the estimate depends on. Because DeployOpen works from a written scope, the timeline in a proposal reflects the inventory agreed before work starts.

What breaks when the rules are too narrow?

The usual failure is a sync that stops with a permission error on a resource kind that was left out of the allow list, leaving an application OutOfSync or Progressing. Other symptoms include a namespace that Argo CD can no longer create, a CRD that cannot be installed, or a cluster-scoped object that a chart expects. Narrow rules can also block rollbacks or health checks if read access was reduced. Test each application against the new policy in a non-production cluster first, and keep the previous ClusterRole available so the rollback path is known before the change window.

How do we verify that the narrowed access works as intended?

Verify in two directions. First, confirm that the intended syncs succeed for every project and that each application reaches a Healthy and Synced state. Second, confirm that Argo CD cannot write outside its granted namespaces and resource kinds, by attempting out-of-scope changes from a test application and reviewing the denials. Check the resulting ClusterRole against the agreed inventory, and record the evidence in the change ticket. Ask for this verification step, with its pass criteria, to appear in the written scope as a named deliverable.

What should we ask for in a written scope for this work?

Request a written scope that lists the clusters in scope, the resource kinds per project, the ClusterRole changes per cluster, the test plan and the rollback plan. Ask who performs discovery, rule design, testing and rollout, and which deliverables are documentation, such as the final roles and the verification evidence. Separate one-time work, such as the initial redesign, from recurring work, such as reviewing new resource kinds when teams add operators or upgrade Argo CD. Also ask how changes to allow lists are approved after handover, because those reviews are the ongoing cost.

Limits to confirm in your environment

The rules Argo CD needs on a managed cluster depend on the version you run, the resource kinds your applications use and how your cluster is configured. Each card below is a point to confirm against the official docs and your own test cluster before you change anything in production.

Exact argocd-manager-role rules

The rules in argocd-manager-role differ between releases, so copy the ClusterRole from the version you actually run instead of relying on examples from older guides. Record the cluster-wide read rules and the write rules separately. Then confirm, on a test cluster, that a sync to a namespace you intend to allow succeeds and that a sync outside that scope is denied with a clear error.

Resource kinds the controller needs

Narrowing write access can silently stop the application controller from reading or reconciling a kind your workloads depend on, such as CRDs, ingress classes or custom operators. List every kind your applications render, including those created by Helm charts and Kustomize overlays, and test each one. Expect some kinds to need read access only and others to need write access in the target namespace.

Impersonation support and configuration

Sync impersonation lets each destination run under a specific Kubernetes identity, but support and setup depend on the Argo CD version and on how the cluster authenticates. Confirm in the official docs whether your release supports it, which fields configure it, and what the cluster's RBAC must grant to the impersonated identity. Test a sync that should pass and one that should fail before relying on it.

Cluster-scoped resource behavior

Cluster-scoped kinds such as Namespaces, CustomResourceDefinitions, ClusterRoles and PersistentVolumes sit outside namespace rules, so a namespace-only write scope will not cover them. Decide which teams may manage these kinds, then check how your project's cluster resource allow list interacts with the ClusterRole on each destination. Confirm the outcome for creation, update and deletion separately.

Default rule changes during upgrades

Upgrades can change how RBAC, resource tracking and default permissions behave, which can break a narrowed ClusterRole without any change on your side. Read the upgrade notes for every minor version between your current release and your target, and rerun your sync and delete tests after each step. Keep the ClusterRole in Git so a drift from your intended rules shows up in review.

Version support window

Only the most recent minor releases receive patch releases, so a narrowed ClusterRole tested on an unsupported version will need retesting after the move to a supported one. Ask which minor versions your organization will run, when each falls out of patch support, and who repeats the permission tests at each upgrade. Keep this schedule with the rest of your change calendar.

Official Argo CD security documentation for this topic

Start with the Argo CD security documentation, the primary source for this topic. Before you change argocd-manager-role, read the sections that describe how Argo CD authenticates to external clusters and what access it needs there. The documentation states that Argo CD needs read access cluster-wide but does not necessarily need full write privileges, and that write access can be limited to specific namespaces and resources by editing the argocd-manager-role ClusterRole on the external cluster. That is the mechanism this topic depends on, so treat it as the baseline your design must justify.

Next, read the material on the repo-server and on how Argo CD renders manifests. The repo-server runs Helm and Kustomize against repository content, so a repository your teams can change may influence what the application controller tries to apply. Narrowing the role limits the damage from a bad render, but it does not replace controlling which repositories each project may use. Also read the sections on credential redaction and TLS between components, since the service account token that backs each registered cluster is exactly the kind of credential you must keep out of logs and API responses.

Before editing, confirm the details against the version you run, because RBAC behavior has changed between releases. Check the upgrade notes for your current minor version, and confirm which resources your applications create so you can list every API group the role must cover. Ask your platform team to record the current role and its bindings in Git so you can diff any change, and plan a test sync against a non-production destination before tightening production clusters. Anything the documentation does not state explicitly should be confirmed on a test cluster, not assumed.

How DeployOpen scopes and delivers least-privilege Argo CD access

DeployOpen plans and implements least-privilege access from Argo CD to managed clusters inside your own infrastructure. We start from what each cluster actually needs, then narrow write access, project allow lists and sync impersonation in a written, fixed scope that your team can review and run after handover.

How we scope

Inventory every destination cluster, namespace and resource kind that Argo CD currently writes to today.
Agree in writing which clusters get cluster-wide read and which get namespace-scoped write.
Define the cluster resource allow lists each AppProject may use, with owners named for each team.
Confirm the Argo CD version and the access model each managed cluster uses before the build starts.

How we build

Edit the argocd-manager-role ClusterRole on external clusters so write access stops at the agreed namespaces and resources.
Configure AppProject destinations, cluster resource allow lists and sync impersonation to match the approved scope.
Test denied actions on each cluster to confirm that out-of-scope writes fail as the written scope requires.
Keep the manifests and access definitions in Git so every change to permissions goes through review.

How we hand over

Document each role, project boundary and destination mapping so your platform team can explain them to auditors.
Walk your engineers through how to request a new namespace or resource kind and how it is approved.
Provide a runbook for rotating cluster credentials and for reviewing access after an Argo CD upgrade.
Record the test results and the final scope as handover evidence for your change and configuration records.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Review access drift when new clusters, teams or Argo CD minor releases change the permissions in use.
Confirm the scope again before any change that widens write access on a managed cluster.
Quote follows from the written scope, so ask for the retainer terms alongside the implementation proposal.