Argo CD application organisation

Three objects with different jobs

An Argo CD Application says what to deploy and where. An AppProject limits the choices its Applications may make. An ApplicationSet generates Applications when many follow a repeatable pattern. None of these is a replacement for Kubernetes RBAC, which decides what an identity may do at the API server.

Decide what changes together

Start with one Application for MicroBank's two API Deployments and Services. Keep its databases, runtime Secret, controllers, and policies under separate owners. This lets you review a workload change without implicitly granting permission to delete persistent state.

An Application identifies a source, revision, path, and destination. An AppProject restricts allowed sources, destinations, and resource kinds. The controller's Kubernetes permissions are a separate layer. An AppProject that allows only one namespace does not automatically make the controller itself namespace-limited.

Scale only when repetition appears

ApplicationSet can generate related Applications from an inventory. It does not automatically implement stage approvals or safe release promotion. A generator reading an untrusted directory or cluster label can expand the deployment boundary if that input is insufficiently controlled.

Before using a generator, operate one Application successfully. Then identify exactly which fields vary: environment, destination, overlay path, and approved revision. Confirm that your installation includes the ApplicationSet controller; the earlier Core installation may not include every optional component.

Read the lab's Application as a sentence

The GitOps lab introduces one Application. Before copying its YAML, translate its fields:

The Application in this path manages Accounts and Ledger workloads. It excludes databases, runtime secrets and delivery controllers because their recovery and permissions differ. That is a practical ownership decision, not a rule that every application needs five repositories.

Try a paper threat test: a proposed commit adds a cluster-wide role. The project's allowed resource kinds should reject that expansion. Now ask who can edit the AppProject itself. If the same unrestricted contributor can remove the restriction, the first check is not an independent control.

Add an ApplicationSet only after operating the single Application. First list the fields that really vary across targets. A generator that creates Applications is useful repetition; it does not decide whether an image has passed QA.

Try it

Draw an ownership table for workload objects, infrastructure, controllers, policies, and secrets. Each object should have one intended reconciler. Then read your Application and answer:

• Can its source reference any repository or only the intended one?
• Can it target controller namespaces or cluster-scoped resources?
• Does deleting it delete its managed resources?
• Who is permitted to edit the Application itself?

The accompanying lab keeps manual sync and no automatic pruning for the first handoff. These settings give you time to inspect each step. Choose production settings separately, based on the required review and recovery controls.

Checkpoint and revision

Explain the differences between an Application, an AppProject, an ApplicationSet, and Kubernetes RBAC. Describe a boundary that still holds when someone submits an unexpected manifest.

Compare your reasoning

If one Application shows OutOfSync, investigate its source and destination. If it is denied by its project, inspect the project's intended restrictions. If the API rejects the controller's request, inspect Kubernetes authorization. These are separate layers with separate repair paths.

Sources

Argo CD projects↗, ApplicationSet↗, ApplicationSet security↗.