Argo CD User Management: Local User Configuration and Permission Separation in Practice
This article was last updated on: June 29, 2026 pm
Introduction
I recently helped a team sort out their Argo CD permissions and found that most teams are still stuck at the “all DevOps/SRE members sharing the admin account” stage. Honestly, this is a cardinal sin in GitOps workflows — who did what and who changed what all gets mixed together, making it impossible to trace issues when something goes wrong.
I’ve been burned by this before: a bunch of people using the same admin account, and one day someone accidentally deleted a Production cluster Deployment. We spent ages trying to figure out who did it with no luck. After that painful lesson, I started taking user management seriously. Today I’ll share my hands-on experience and the complete workflow for configuring Argo CD local users.
Here’s the bottom line: Once your team exceeds 3 people, you must implement permission separation.
│ 📝Notes: This article assumes you already have Argo CD installed.
Why Do You Need Local Users?
Many people’s first reaction is: why not just set up LDAP / OIDC single sign-on?
Sure! That’s great. But the reality is often:
- The team is small and there’s no dedicated IAM team
- The approval process for integrating with enterprise LDAP takes two months
- You don’t want to overcomplicate test environments
In these cases, Argo CD’s built-in local user mechanism is the optimal solution — lightweight, flexible, and works out of the box.
Argo CD’s Default User Model
After installing Argo CD, there’s only one built-in user: admin. It has the highest privileges and can perform almost all operations.
│ 🤔 Here’s the question: if developers, testers, and ops all use the same admin account, guess who gets blamed?
The answer is obvious: ops takes all the blame when things go wrong. Because there’s no way to determine who performed the operation.
So our goal is: create independent users for different roles and grant the minimum necessary permissions.
Configuring Local Users via ConfigMap: Core Approach
Argo CD’s user management and permission configuration are all handled through ConfigMaps. Specifically:
- argocd-cm: Defines user login names and password hashes
- argocd-rbac-cm: Defines roles and permission policies
After modifying these two ConfigMaps, Argo CD automatically reloads the configuration without requiring a Pod restart. That’s a nice experience.
Step 1: Modify argocd-cm to Add Users
First, edit the argocd-cm ConfigMap:
1 | |
Add accounts.xxx fields under data. For example, to create a user named devops:
1 | |
- accounts.devops: login: Allows this user to log in via UI or CLI
- accounts.devops.enabled: “true”: Enables this user
│ 📝Notes: login means the user can log in. You can also use apiKey to restrict access to API-only.
Step 2: Set the Password
It’s recommended to use the argocd admin initial-password or update-password command:
1 | |
Step 3: Configure RBAC Permissions
Having users alone isn’t enough — you also need to tell Argo CD what each user can do. That’s where argocd-rbac-cm comes in.
Edit it:
1 | |
Add policies under data. Let me walk you through this — I want the devops user to only manage dev and staging environments, with no access to production:
1 | |
Line-by-line explanation:
- policy.default: role:readonly: All users without explicit authorization default to read-only
- p, role:devops, applications, get, dev/*, allow: The role:devops role has get permission on resources in the dev project
- p, role:devops, applications, sync, dev/*, allow: Has sync permission (can trigger manual syncs)
- g, devops, role:devops: Assigns the devops user to the role:devops role group
The result: after the devops user logs in, they can only see dev and staging projects and cannot operate on production. ✅
│ 📝Notes: For even finer-grained control, you can restrict access to specific clusters — for example, only allowing operations on applications in a particular cluster.
Step 4: Verification
Log in to the Argo CD UI with the new user, or via CLI:
1 | |
Enter the password — you should be able to log in successfully. Then try accessing the production project — you’ll see a 403 Forbidden. 🎉
Looking Back: My 3 Best Practices
After hands-on experience, here are a few lessons learned:
1. Create Independent Users for Each Team
Here’s my recommended approach:
| User | Team | Permission Scope |
|---|---|---|
| devops | DevOps | Full permissions on dev / staging projects |
| qa | QA Team | Sync permissions on test environments |
| audit | Audit | Global read-only |
| sre | Site Reliability Engineers | Full permissions on all projects |
This way, when something goes wrong, you can check the logs and immediately identify who performed the operation.
2. Rotate Passwords Regularly
Don’t just set a password and forget about it. My recommendations:
- Rotate passwords every 90 days
- Use a password manager (e.g., Bitwarden / 1Password) to store them
- Use scripts for batch updates
Why rotate regularly? Because local user passwords are static — once leaked, an attacker can take control of your entire GitOps workflow.
│ 📝Notes: If your organization has an IAM team, I strongly recommend integrating with LDAP / OIDC as soon as possible to centralize password management.
3. Principle of Least Privilege
Don’t take the easy route and grant everyone the admin role. My recommended approach:
- Read-only access: 90% of team members only need to view, not modify
- Write access: Only DevOps leads and SREs should have this
- Admin access: Only 1-2 people, used for managing users and configuration
The worst case I’ve seen was a test engineer with admin privileges who accidentally deleted the entire Argo CD configuration — recovering from that was an absolute nightmare.
Going Advanced: Managing User Configuration with Helm Values
If you installed Argo CD with Helm, you can configure everything directly in values.yaml to avoid manually editing ConfigMaps:
1 | |
Then run helm upgrade and the configuration takes effect.
Next, use the argocd admin initial-password or update-password command to set the password:
1 | |
Summary
Argo CD’s local user management mechanism isn’t actually complicated. The core is just three steps:
- Define users in ConfigMap (argocd-cm)
- Set passwords
- Configure RBAC policies (argocd-rbac-cm)
But what truly matters is the awareness of permission separation and password security. Don’t share the admin account just because proper setup feels like a hassle — it will eventually bite you.