You've been deploying your own applications across waves with perfect control. Now imagine a team: frontend engineers deploying to the frontend namespace, backend engineers deploying to the backend namespace. They can't cross boundaries—a frontend engineer must never touch backend deployments.
This is where ArgoCD Projects and RBAC (Role-Based Access Control) become critical. Projects define what repositories your team can deploy from and which clusters/namespaces they can deploy to. RBAC policies define who can do what—read-only viewing, deployment approvals, admin access.
Without Projects and RBAC, one engineer's mistake could deploy malicious code to production. With them, you enforce organizational boundaries and isolate team deployments.
Consider a team of six engineers:
If ArgoCD had no Projects or RBAC, all six engineers would have access to everything. A misconfiguration by the frontend team could accidentally overwrite the backend database password, breaking production.
Projects solve this: Each team gets a Project that restricts source repositories and destination namespaces.
RBAC solves this: Each engineer gets a Role that defines what actions they can take.
An AppProject is a Kubernetes custom resource that acts as a security boundary. It defines:
Let's look at the structure:
Output:
Notice the hierarchy: source repos → destinations → resource restrictions.
The first security boundary is the repository. Your Project defines which Git repositories its Applications can deploy from.
Output:
A single project can deploy from multiple repositories. This is useful when your deployment includes both application code and shared infrastructure:
Output:
The second security boundary is the destination—where your Application can deploy.
Output:
Some organizations deploy to multiple clusters (us-east, eu-west, etc.). You can restrict Projects to specific clusters:
Output:
The third security boundary controls resource types. Some organizations block certain resources from being deployed through ArgoCD.
Output:
Some organizations take the opposite approach—whitelist only resources they trust:
Output:
Now that you've defined Projects, you need to define which users can access them. RBAC in ArgoCD uses two policy types:
ArgoCD RBAC is configured in a ConfigMap. The format uses three parts:
Create a read-only role that can view but not modify:
Output:
Allow a developer to deploy only within their project:
Output:
The policy syntax uses * as a wildcard:
Examples:
ArgoCD 3.x adds the ability to restrict repositories at the project level, not just globally.
Combine all three boundaries—repositories, destinations, and RBAC:
Output:
Let's apply these projects to your Minikube cluster and verify they work.
Output:
Output:
Output:
Output:
Now create an Application that uses the backend-team project:
Output:
ArgoCD 3.x adds fine-grained permission controls that earlier versions lacked.
Example of repository-scoped RBAC:
Output:
Setup: You have your Minikube cluster running with ArgoCD installed. You want to set up multi-team access control.
Prompt 1: "I have two teams: frontend (3 engineers) and backend (2 engineers). Design an ArgoCD AppProject and RBAC configuration that isolates frontend team to frontend namespaces and backend team to backend namespaces. Include the full YAML and the RBAC ConfigMap."
Prompt 2: "In your RBAC configuration, I want to also allow both teams to read (but not modify) logs and sync status. Add these permissions without allowing cross-team deployment."
Prompt 3: "Give me kubectl commands to apply this setup and verify that a frontend engineer can sync frontend applications but cannot touch backend ones."
You built a gitops-deployment skill in Chapter 0. Test and improve it based on what you learned.
Ask yourself:
If you found gaps: