The Hidden Dangers of Defaults: Securing Multi-Tenant Argo CD Install...
summary
Argo CD ships with an overly permissive default app project that lets any app read any repo, create cluster‑wide RBAC, and deploy to any namespace or cluster; that combination enables repo supply‑chain attacks and privilege escalation. Fixes include lock down default app project, create per‑team AppProjects with sourceRepos whitelists, clusterResourceBlacklist and namespace/cluster allowlists, deny creation of Application and AppProject resources for most users, enable SSO and disable the admin user, and adopt the alpha destination service accounts (impersonation sync) to narrow sync-time privileges.
AI-written summary · about
chapters (18)
- 0:00Argo CD security risks
- 1:44Introduction
- 2:45Single-tenant to multi-tenant
- 3:49Multi-tenant security needs
- 5:15Argo CD security and access control
- 6:38Argo CD RBAC model
- 8:47Policy syntax examples
- 13:00Restrict Kubernetes access
- 13:20Why restrict resource creation
- 14:02Locking default app project
- 15:05Prevent cluster role creation
- 16:08Restrict Git repository access
- 17:14Prevent namespace overrides
- 18:38Blacklist app creation
- 19:42Blacklist app project creation
- 20:46Kubernetes RBAC vs Argo CD
- 21:51Impersonation sync
- 23:156 key takeaways
related talks
24mManaging Argo CD Multi-Tenancy Effectively
31mAttacking Argo CD with Argo CD (and then Defending)
26mThreat Model Report: Security Considerations for Hardening D...
26mThreat Model Report: Security Considerations for Hardening D...
22mTaming the Chaos: Fine-Grained RBAC in Argo CD for Incident Avoidance
38mMulti-Tenancy For Argo Workflows And Argo CD At Adobe
24mEnhancing Compliance and Safety with Argo CD Ephemeral Access
21mMulti-Tenant ArgoCD with security and isolation