Projects, multi-cluster & RBAC

Boundaries and permissions.

An Argo CD Project (AppProject) is a boundary that groups Applications and constrains what they may do: which Git repos they can source from, which clusters and namespaces they can deploy to, and which resource kinds they may create. In a shared Argo CD serving many teams, projects are how you keep team A from deploying to team B’s namespace or from a repo it does not own. The default project is unrestricted, so real deployments define scoped projects.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata: { name: payments, namespace: argocd }
spec:
  sourceRepos: ["https://git.acme.internal/payments/*"]   # only these repos
  destinations:
    - { server: https://prod-cluster, namespace: "payments-*" }   # only here
  clusterResourceWhitelist: []          # no cluster-scoped resources
  namespaceResourceBlacklist:
    - { group: "", kind: "ResourceQuota" }

Multi-cluster and RBAC

Argo CD manages multiple clusters by holding credentials for each (registered as cluster secrets) and deploying to them per an Application’s destination. On top of projects, Argo CD has its own RBAC that governs who can do what in the UI/API — which users/groups can sync, create apps, or administer, scoped by project. Wire it to SSO (OIDC/SAML) so identities come from your IdP, and grant least privilege: most users need sync on their project, not admin.

policy.csv: |
  p, role:payments-dev, applications, sync, payments/*, allow
  p, role:payments-dev, applications, get,  payments/*, allow
  g, acme:payments-team, role:payments-dev
# groups come from SSO; this role can sync its own project’s apps and nothing else