ArgoCD RBAC and project isolation design

[ritzorama]

Before we deploy ArgoCD to production, we need to design the RBAC model. Key decisions:

Project isolation:
Each team gets an ArgoCD Project scoped to their namespaces. Cross-project access denied by default.

Proposed role mapping:

• Platform team: admin on all projects
• Team leads: admin on their team's project
• Developers: readonly across all apps, sync on their team's apps
• CI/CD robots: override on their team's apps (for automated deploys)

SSO integration:
GitHub OAuth groups -> ArgoCD RBAC roles via ConfigMap. Format: g, github-org:team-name, role:name

Proposing an ArgoCD AppProject CRD per team as the isolation unit. Thoughts?

[CodeAhmedJamil]

The project-per-team model is right. One addition: add a platform project with cluster-scoped access for platform team resources (cert-manager, ingress-nginx, ArgoCD itself). Team projects should be namespace-scoped only.

[arjunmehta-git]

Agreed. Also: bake in the sync window policy. Production syncs should be allowed only during business hours + on-call coverage (block the 2am auto-syncs). ArgoCD SyncWindows handles this - let's default to 'allow during business hours, manual override available'.

[hortison]

On the CI/CD robot role - override is very broad. It bypasses sync windows and resource hooks. I'd use sync only for robots unless there's a specific need for override. Least privilege applies here too.

[ritzorama]

@hortison good catch - changing robot role to sync with override available via explicit AppProject flag only. Will document when to enable override.