Locking down the Argo CD default project

Why the Argo CD default project is a gap in multi-tenant setups

The Argo CD default project permits deployments from any source repository, to any cluster and of all resource kinds, and it can be modified but not deleted. Any application that does not name a project lands in this permissive default, so a shared Argo CD instance has a silent path around every boundary you draw for individual teams. The gap matters most once one instance serves several teams, several clusters or both, because a single misplaced application can pull manifests from a repository nobody reviewed or write resources into a cluster another team owns.

The risk grows with each new team, cluster and contributor who can create applications. A single-team instance on one cluster may tolerate the default for a while, but a shared instance with multiple clusters and separate tenants should treat it as an open door. Before you change anything, list who can create applications, which repositories they use, and which clusters are registered. That inventory tells you how much the default project currently allows and which scoped projects you need to replace it. Confirm the current state against your own instance, since the defaults can differ on an instance that was installed or upgraded in a non-standard way.

Locking the default project is a configuration and planning task, not a license purchase. Argo CD is released under the Apache License 2.0 (SPDX: Apache-2.0), and the project offers no paid edition, so the cost sits in the engineering time to design projects, move applications and test the result. The work is largely one-time, although each new team or cluster will need a scoped project and a review of its access. Ask any partner for the scope of that migration in writing, including which applications are affected and how the change will be verified, so the quote reflects your instance rather than a generic template. The Argo CD projects guide is the reference for the settings this work changes.

Lockdown options for the default project and when each fits

This table compares the main ways to narrow the Argo CD default project: emptying its source and destination lists, restricting resource whitelists, or leaving it open as a sandbox catch-all. Read each row against your existing applications, because the options differ in what they block and in what they break when applied to a running installation.

Option	What it blocks	When a platform team picks it
Empty sourceRepos and destinations	Deployments from any Git repository and to any cluster, so the default project cannot deploy anything until an application is moved into a scoped project	Standard choice for a production installation where every application should belong to a named project from the start
Restrict clusterResourceWhitelist	Cluster-scoped resource kinds such as namespaces or custom resource definitions, unless the kind is listed	Useful when teams may deploy namespaced workloads but platform teams must own cluster-wide objects
Restrict namespaceResourceWhitelist	Namespaced resource kinds not listed, so the project cannot create unlisted workload types	Useful when a team should deploy only specific kinds, for example Deployments and Services, to its namespaces
Keep the default project open as a sandbox	Nothing, so any repository, cluster and resource kind remains allowed under the default project	Fits a throwaway or learning installation where speed matters more than boundaries, and should not hold shared production apps
Empty lists before moving applications	Nothing by itself, but applications still in the default project will show sync errors once the lists are empty	Safe order: create scoped projects, move each application, confirm sync, then empty the default project lists
Modify but do not delete the default project	Deletion is not possible, so the project remains and must be narrowed in place	Relevant because teams often assume the default project can be removed; confirm the behavior in the projects guide before planning

Steps to empty the default project and move applications into scoped projects

This sequence moves every Argo CD application out of the default project and into AppProjects with explicit sources, destinations and resource lists, so the default project can be emptied without breaking running deployments.

Inventory applications still in the default project
Before changing anything, list every Application that points at the default project. Run argocd app list -o wide or query the Application resources with kubectl get applications -n argocd -o custom-columns=NAME:.metadata.name,PROJECT:.spec.project and record each application's name, source repository, destination cluster and namespace, and sync status. Ask the owning team to confirm which repository and cluster each application should keep, because the scoped project you write in the next step must allow exactly those. The step is done when you have a complete list with an owner for every entry and no application is unaccounted for.
Define scoped AppProjects for each team
Create one AppProject per team or workload group as a Kubernetes manifest kept in Git. Set spec.sourceRepos to the repository URLs that team owns, spec.destinations to the specific cluster and namespace pairs it deploys to, and spec.clusterResourceWhitelist and spec.namespaceResourceWhitelist to the resource kinds its applications actually create. Avoid wildcards unless a team has a documented reason for them. Apply the manifests and confirm with argocd proj list and argocd proj get <name> that each project shows only the sources, destinations and resource kinds you wrote. The step is done when every inventoried application has a matching project with no missing entries.
Bind project roles to SSO groups
Where a team needs to sync its own applications, add project roles with policies scoped to that project and bind them to the matching identity provider group through your SSO configuration. This keeps sync rights tied to the project rather than to the default project. Confirm the binding by logging in as a test user from that group and checking that they can see and sync only their project's applications. The step is done when a team member can operate their applications through the scoped project without any access to the default project.
Move each application to its scoped project
Update each Application manifest so spec.project names its new AppProject, commit the change to Git, and let Argo CD reconcile it. Move applications in small batches, starting with a non-production application, so one failure does not affect the whole set. Argo CD will reject an Application whose source or destination is outside its project, so a sync error at this point usually points to a missing allow-list entry rather than a broken deployment. The step is done when the Application's project field shows the new name and its status returns to the state it had before the move.
Verify project membership and sync status
After each batch, list applications by project with argocd app list -p <project-name> and confirm that every application appears under its intended project and that none remain in default. Check that each one reports the same sync status it had in the inventory, and that no application is stuck in OutOfSync or Degraded because of a project restriction. Compare the results with your inventory from the first step. The step is done when the default project lists zero applications and every other project lists exactly the applications you assigned to it.
Empty the default project's sources and destinations
With no applications left in the default project, edit it to set spec.sourceRepos and spec.destinations to empty lists. The default project cannot be deleted, but emptying these fields stops it from permitting deployments from any repository to any cluster. Apply the change through Git if your Argo CD configuration is managed declaratively, and confirm with argocd proj get default that both lists are empty. The step is done when the default project shows no allowed sources or destinations and no new application can be created against it.
Test the lockdown and keep a rollback path
Attempt to create a test Application in the default project and confirm that Argo CD rejects it. Then record the rollback path for each batch: revert the Application's spec.project field in Git to its previous value, or temporarily restore the default project's sourceRepos and destinations from the Git history, and let Argo CD reconcile. Keep the rollback steps in your change record so an on-call engineer can follow them if an application stops syncing after a move. The step is done when the rejection is confirmed, the rollback procedure has been tested on one application, and the change record is filed.

Security risks that remain after the default project is locked

Emptying the default project closes one gap, but Argo CD still trusts whoever can create applications, whoever holds broad project roles, the content of every repository it renders, and any local admin account left enabled. Each card below names one of these remaining risks and the check that confirms it is closed.

Applications created under the default project

Anyone with permission to create an Application can set its project field to default unless RBAC stops them. An emptied default project blocks deployment targets, but it still accepts the application record, so the application sits outside your team scopes and is easy to miss in reviews. Check that your RBAC policy grants create and update only on named projects, and list applications with argocd app list -p default on a regular schedule to confirm none exist.

Overly broad project roles

Project roles that carry wildcard actions or applications permissions on */* let a team sync, delete or override workloads outside its own scope. A project can look tightly bounded on its source and destination lists while its roles still grant more than the team needs. Review each role's policy lines and its SSO group bindings, and confirm that delete and override actions are granted only where a named owner needs them.

Repo-server running content from untrusted repositories

The repo-server runs Helm and Kustomize on repository content, so a chart, Kustomize overlay or referenced file from an untrusted source can execute logic and read files the renderer can reach. Locking sourceRepos limits which repositories a project may use, but it does not validate what those repositories contain. Confirm that only repositories your organization controls are allowed, that out-of-tree file access is restricted, and that the repo-server runs with the least network and filesystem access your platform allows.

Built-in admin user still enabled

The built-in admin account bypasses the project and RBAC design you built, and it is a shared credential that shows up poorly in audit trails. The user management guidance says to use it only for initial setup and to set admin.enabled to false once local users or SSO are configured. Before you disable it, confirm that at least one SSO group or local user holds an administrator role and that break-glass access is documented and tested.

Unpinned upgrades that change security defaults

Security behavior changes between major versions, so a locked default project can drift when an upgrade alters RBAC or resource handling. The 2.14 to 3.0 notes changed update and delete RBAC to apply only to the application itself and required an explicit logs, get permission for log access. Record your Argo CD version, read the upgrade notes before each minor move, and rerun your project and RBAC checks in a staging instance after every upgrade.

Who changes what: platform team, application teams and auditors

The platform team owns the Argo CD configuration, including the default AppProject. Once its sourceRepos and destinations lists are emptied, the platform team is the only group that should need to change it, and any change to it should happen through the same Git review path as other platform code. The project cannot be deleted, so the platform team's job is to keep it closed and to route all real workloads into named projects.

Empty the default project deliberately: Remove entries from sourceRepos and destinations in the default project so new applications cannot silently inherit broad permissions.
Create global projects for shared platform components: Define separate projects for cluster add-ons and platform services, each with an explicit repository list and destination set.
Restrict who can edit projects: Limit update and create rights on AppProject objects to platform administrators through your RBAC policy.
Move existing applications before locking: Find applications still pointing at default and reassign them to scoped projects, so the lock does not break running syncs.
Manage the change in Git: Store every project manifest in a repository the platform team controls, with review by a second person.

Before you lock the default project, confirm your Argo CD version and RBAC model with the Argo CD projects guide and test the change in a non-production instance.

Application teams deploy their services through Argo CD, but they should work only inside projects that the platform team has scoped to their repositories, namespaces and clusters. Their authority is defined by the project they belong to, not by the applications they create. When they need a new repository, cluster or resource kind, the request goes to the platform team rather than being added to their own project by hand.

Create applications within their assigned project: They can define Application objects that point to the project name their team was given.
Cannot widen project scope: They cannot add repositories, destinations or cluster-scoped resource kinds to their project unless their role grants project editing.
Cannot fall back to the default project: Applications that name a project which is not theirs, or that name the empty default project, should fail to sync.
Sync and roll back within their scope: Their RBAC grants apply to applications they own, so they can operate their own workloads without touching the platform.
Request changes through review: Scope changes go through a pull request that the platform team approves.

Check that each team's SSO group maps to exactly one project role, and test that an application with an out-of-scope repository is rejected.

Compliance reviewers need to see how the Argo CD configuration controls change, not only whether it is currently set. A locked default project and project manifests stored in Git can show the intended permission boundaries and how those boundaries changed over time. This is evidence that your team can produce, but it does not amount to an audit opinion or certification, which only an independent assessor can give.

Project manifests as the boundary record: The AppProject files in Git list the allowed repositories, destinations and resource kinds for each team.
Git history as the change record: Commits, pull request approvals and author identities show who changed a project and when.
Default project state as a control check: A review can confirm that sourceRepos and destinations in default are empty.
Live state as a comparison point: Compare the cluster's current projects with the Git manifests to detect drift.
Scope limits to state: Document which controls were tested, the Argo CD version in use and any exceptions.

Ask your assessor which evidence they want from Argo CD, and confirm with them how the controls map to the frameworks you are assessed against.

Limits and what to confirm in your environment

The default project is a shared fallback, so changing it can affect applications you did not plan to touch. The cards below list what to check in your own Argo CD before you empty its sources and destinations. Each check reduces the chance that a lockdown breaks a sync or leaves a gap in project boundaries.

Confirm your Argo CD version

Start by confirming which Argo CD minor version you run and whether your upgrade notes cover it. Patch releases are only published for the three most recent minor versions, so an older line may no longer receive fixes. Upgrade notes for the 2.14 to 3.0 move change how RBAC and resource tracking behave, which can alter what a project change affects. Record the exact version before you edit the default project, and plan the change against that version's documentation rather than a newer one.

Find apps that rely on default

List every Application whose spec.project is default, including apps created by ApplicationSets, Helm charts or older scripts. Emptying the default project's sourceRepos and destinations will block those applications on their next sync. Export the list with the Argo CD CLI or the API, then group the apps by repository and cluster. Agree with each owning team which project each app should move to before you change anything shared.

Map SSO groups to project roles

Confirm how your identity provider groups reach Argo CD, whether through a direct OIDC connection or the bundled Dex connectors. Check which groups are bound to roles in each project and whether any user can act through the default project only because of a broad global role. Once the default project is empty, users who relied on it will receive permission errors, so the group-to-role mapping must already cover every team that deploys.

Verify project field behavior

Read the projects guide for the version you run and confirm how sourceRepos, destinations and the cluster and namespace resource lists are evaluated. Test an empty list with a non-production application to see whether the sync is denied, and whether the error message names the project. Do not assume the behavior matches an older release or a blog post. Record what you observed so the change record shows the test.

Check cluster registrations

Confirm that no cluster you manage was registered with access that depends on the default project. Review the Secrets that hold cluster and repository definitions and check their project labels, then trace which project each registered cluster is used from. If a registration has no project scope, it can still be reachable from the default project after you change it. Note any cluster that needs an explicit project entry in its destinations before you empty the default project.

Confirm the change path and rollback

Confirm who may edit the default project and how that change is reviewed and recorded. Because the project is part of the Argo CD configuration, a manual edit in the UI can drift from the Git source of truth and be overwritten later. Decide how the empty lists will be stored, who approves the change, and how you will restore the previous values if an application stops syncing. A written rollback step is the fastest way to recover from a missed dependency.

Questions teams ask before locking down the default project

How much effort does it take to lock down the Argo CD default project?

The change itself is small: empty the sourceRepos and destinations lists on the default project, which the Argo CD projects guide describes as the way to lock it down. The effort sits in everything around that edit. Each application currently relying on the default project must be found, assigned to a scoped project, and checked against that project's allow lists before the change lands. Teams should ask for the work to be scoped as inventory, reassignment, validation and handover, with each step written down in the quote rather than assumed to be a single command.

What drives the effort of locking down the default project?

Three inputs move the effort most:

The number of applications still assigned to the default project, since each one needs an owner and a destination project.
The number of Git repositories those applications pull from, because every repository must be mapped to a project's allowed sources.
The number of clusters they deploy to, because each destination needs a namespace and server rule in the right project.

Secondary drivers include how many teams share the instance, whether applications use Helm or Kustomize from several repositories, and how much of the current configuration is recorded in Git versus edited by hand in the cluster.

Can our team lock down the default project without outside help?

Yes, for a small installation with few applications, one or two repositories and clusters, and an engineer who knows the project model. The change is a short edit, so the difficulty is in the inventory and the reassignment rather than the YAML. Teams with many applications, several tenants, or no one who owns the Argo CD configuration usually find the review takes longer than the edit. A partner can run the inventory and validation under a fixed scope, while your team keeps ownership of the projects and approves each change.

What do we need to provide for the work?

Plan for four inputs before work starts:

Read access to the Git repositories that hold Argo CD application and project definitions, so existing configuration can be reviewed.
Admin access to the Argo CD instance, with the ability to view and edit AppProjects.
Cluster administrator access, or a delegated contact, for the destination clusters so namespace and server rules can be checked.
A change window agreed with the application owners, because some applications will need reassignment and a sync check afterward.

Confirm in the written scope who approves each project change and who answers questions about business-critical applications.

How long will locking down the default project take?

The duration depends mainly on the number of applications still using the default project, the number of owning teams that must confirm their assignments, and how many repositories and clusters they touch. No duration is given here because none has been established for your environment. Ask for a timeline in the written scope that separates the inventory phase, the team review, the reassignment and the post-change verification, and confirm which of those phases depend on people outside the platform team.

Will locking down the default project break running applications?

It can, if an application still depends on the default project's open permissions. Once sourceRepos and destinations are emptied, Argo CD stops allowing syncs from any repository or to any cluster through that project, so an application that was never reassigned can fail to sync. Safe practice is to find every affected application first, move each into a project that explicitly lists its repository and destination, and then empty the default project. Check that applications stay healthy and in sync after the change, and keep a rollback path in the plan.

Does locking down the default project change who can deploy?

It changes what the default project allows, not who holds Argo CD roles, but the two work together. Once the default project is empty, deployments must go through projects whose sources, destinations and resource kinds were deliberately set, and project roles and SSO group mappings decide which people can act in each one. Teams should review their project roles alongside the default project change, so no one loses the ability to deploy without a planned alternative.

How DeployOpen scopes a default project lockdown

DeployOpen plans and implements Argo CD inside your own infrastructure, so the default AppProject change is made in the cluster and Git repositories you control, under your change process. In an engagement, the lockdown is one item in a written scope that also covers how the projects that replace default are designed, which repositories and destination clusters each team may use, how SSO groups map to project roles, and how the change is rolled out without breaking applications that still point at default. The scope states which namespaces, clusters and applications are in view, what is delivered (the emptied default project, the replacement projects, the migration of existing Applications and the verification record), and what you must provide, such as repository lists, cluster inventories and named owners for each team.

Most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, so you know what will and will not be changed. For this topic, the fixed scope usually depends on how many Applications still reference default, how many repositories and clusters your teams use, and whether any existing project already needs to be tightened. Ask for those inputs to be listed explicitly in the quote, and confirm with your own team how the change will be approved and whether it needs a change window. The Argo CD projects guide is the reference both sides should use when reviewing the scope.

Ongoing support is available as a retainer for work that continues after the first rollout. Typical retainer items for this topic include reviewing new Applications for project assignment, adjusting project allow lists as new repositories and clusters are onboarded, and checking Argo CD upgrades for changes that affect project behavior. Confirm with DeployOpen what the retainer covers, how requests are prioritized and what response expectations apply before you sign, because those terms belong in the written agreement rather than in this page.

How DeployOpen delivers Argo CD project isolation

DeployOpen plans, builds and hands over the default project lockdown as part of a scoped Argo CD engagement in infrastructure you control. Each step produces written scope, tested configuration and documentation your platform team can maintain after handover.

How we scope

Inventory every application, repository and destination cluster currently attached to the default project before any change is made
Agree in writing which team owns each new AppProject and which repositories and namespaces it may use
Record the engagement as fixed-scope, with deliverables and timelines agreed before work starts

How we build

Empty the default project's source repository and destination lists, then move applications into named projects one team at a time
Test that a sync from an unlisted repository or cluster is rejected, and that existing workloads keep syncing
Bind project roles to your SSO groups so access follows your identity model rather than local accounts

How we hand over

Deliver the project manifests, RBAC mapping and a runbook for adding a new team or repository
Walk your platform and application engineers through the change flow so new applications are created in a scoped project
Confirm with your team which checks and evidence you need to retain for change and configuration reviews

How we support

Offer ongoing support, upgrades and continuous testing as a retainer if you want DeployOpen to keep the project model current
Review project boundaries when teams, clusters or repositories change, and when Argo CD minor versions are upgraded
Keep the retainer scope in writing so responsibilities for each change stay clear