Summary and recommendation
Argo CD user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Argo CD is a free, open-source GitOps continuous delivery tool for Kubernetes. It has no native SCIM support at any tier. User lifecycle management relies on direct Kubernetes ConfigMap edits, the argocd CLI, or SSO group bindings via the bundled Dex identity provider (SAML, OIDC, LDAP).
Akuity offers a managed service layer on top of open-source Argo CD, but does not publicly document SCIM support either.
Quick facts
| Admin console path | Settings > Accounts (web UI) or kubectl/argocd CLI; no dedicated GUI admin console for user management |
| SCIM available | No |
| SCIM tier required | Open Source (Free) |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| admin (built-in) | Superuser with unrestricted access to all Argo CD resources and actions. Bypasses RBAC enforcement. | Cannot be deleted; can only be disabled via admin.enabled: "false" in argocd-cm ConfigMap. | Free (open source) | No seat cost | Initial admin password is stored in argocd-initial-admin-secret Kubernetes Secret. Best practice is to disable admin after setting up SSO or additional local users. |
| role:readonly (built-in) | Read-only access to all Argo CD resources. Assigned as default fallback role via policy.default in argocd-rbac-cm. | Cannot create, update, delete, or sync applications or any other resources. | Free (open source) | No seat cost | All authenticated users receive at least the permissions granted by policy.default. If policy.default is omitted or empty, users can log in but see no apps or projects. |
| Local user (custom) | Capabilities are explicitly defined per user: 'apiKey' (generate JWT tokens for API access) and/or 'login' (UI/CLI login). RBAC policies must be separately assigned in argocd-rbac-cm; otherwise the user falls back to policy.default. | No group membership, no login history, no self-service password reset. Cannot exceed 32 characters in username. | Free (open source) | No seat cost | New local users have no access until a password is explicitly set via 'argocd account update-password'. Passwords are bcrypt-hashed and stored in argocd-secret Kubernetes Secret. |
| SSO user (via Dex or external OIDC/SAML/LDAP) | Authenticated via external IdP. Permissions determined by RBAC group bindings in argocd-rbac-cm. Supports group-based role assignment. | Group membership is evaluated only at login time (not continuously). No SCIM provisioning; user lifecycle managed entirely in the IdP. | Free (open source) | No seat cost | Some OIDC providers (e.g., Okta) do not return group claims in the ID token; requires enableUserInfoGroups: true and userInfoCacheExpiration configuration. Group sync occurs only at authentication time. |
Permission model
- Model type: custom-roles
- Description: Casbin-based RBAC. Two built-in roles (role:readonly, role:admin). Custom roles and group bindings are defined in the argocd-rbac-cm ConfigMap using a CSV policy syntax: 'p,
, , , - Custom roles: Yes
- Custom roles plan: Free (open source)
- Granularity: Resource-level and action-level. Resources include: applications, applicationsets, clusters, repositories, repocreds, certificates, accounts, gpgkeys, logs, exec, extensions, projects. Actions include: get, create, update, delete, sync, override, action. Application-specific policies support sub-resource targeting (e.g., delete//Pod//*). Glob and regex match modes supported.
How to add users
- Edit the argocd-cm ConfigMap in the argocd namespace: kubectl -n argocd edit configmap argocd-cm
- Add an entry under data for the new user with desired capabilities: accounts.
: apiKey,login (capabilities: 'apiKey' to generate JWT tokens, 'login' for UI/CLI access). - Optionally set accounts.
.enabled: "false" to create the account in a disabled state. - Apply the ConfigMap change. Argo CD reconciles automatically.
- Set the user's initial password via CLI (requires admin credentials): argocd account update-password --account
--current-password --new-password - Assign RBAC policies in argocd-rbac-cm ConfigMap under policy.csv, e.g.: p,
, applications, get, /, allow - Verify the user was created: argocd account list
Required fields: username (max 32 characters), capabilities (apiKey and/or login), password (must be set explicitly before user can authenticate)
Watch out for:
- New users have no access until a password is explicitly configured via CLI or by directly writing a bcrypt hash to argocd-secret.
- Users without explicit RBAC rules fall back to the policy.default role in argocd-rbac-cm.
- If using both local users and SSO, assign policies directly to local users rather than using role bindings to avoid name collision with SSO group scopes.
- The official documentation primarily describes user management via the argocd CLI; managing users without CLI access requires direct Kubernetes Secret and ConfigMap manipulation.
- A user must be defined in only one section (extraConfig or localUsers in the Argo CD CR); if defined in both, extraConfig takes precedence (Red Hat OpenShift GitOps Operator behavior).
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Free (open source) - SSO via bundled Dex supporting OIDC, SAML, LDAP, GitHub, and others. No SCIM. User lifecycle managed in the IdP; group-to-role mappings configured in argocd-rbac-cm. |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Both deactivation and deletion are supported. Deactivation: set accounts.
.enabled: "false" in argocd-cm; the account remains in configuration, secrets and tokens are preserved, but the user cannot authenticate. Deletion: remove the user's entry from argocd-cm; the user disappears from account list, but the bcrypt password hash and token entries remain in argocd-secret and must be manually removed.
- Edit argocd-cm ConfigMap: kubectl -n argocd edit configmap argocd-cm
- Add or set: accounts.
.enabled: "false" - Apply the change. The user account remains in configuration but cannot authenticate via UI or API tokens.
- To re-enable: set accounts.
.enabled: "true"
| Data impact | Behavior |
|---|---|
| Owned records | Argo CD does not assign ownership of applications or projects to individual users. Applications and projects persist independently of user accounts. |
| Shared content | Applications, projects, repositories, and cluster configurations are not user-owned and are unaffected by user removal. |
| Integrations | API tokens issued to the user are invalidated when the user is deleted (entry removed from argocd-cm). If only disabled, existing tokens are preserved but cannot be used for authentication. |
| License freed | No license cost associated with users; no seat to free. |
Watch out for:
- Removing a user from argocd-cm does not automatically delete the user's password hash or token entries from argocd-secret; these must be manually cleaned up.
- Disabling a user preserves secrets and token renewal timers continue to run if configured.
- For SSO users, access is revoked by removing the user or group from the IdP or by updating RBAC group bindings in argocd-rbac-cm; there is no Argo CD-side user record to delete.
- RBAC policy entries referencing the deleted user in argocd-rbac-cm are not automatically removed and should be cleaned up manually.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Open Source | Unlimited users, full feature set, self-hosted. No per-seat cost. | Free |
| Akuity Platform (managed service) | Managed Argo CD instances. Free trial: 1 instance, 20 apps, 3 clusters for 14 days. | $99/month per 10 apps + 10 Kargo stages (app-based billing, not seat-based) |
| Akuity Enterprise | 24/7 support, SLAs, SOC 2 compliance. | Contact for pricing |
- Where to check usage: argocd account list (CLI) or Settings > Accounts in the Argo CD web UI to list all local accounts and their enabled/disabled status.
- How to identify unused seats: No built-in last-login tracking or audit log for local users. Local users do not provide login history. For SSO users, login activity must be tracked in the IdP. Unused local accounts can be identified by checking if a password has ever been set in argocd-secret.
- Billing notes: Open source Argo CD has no licensing or seat costs. Akuity Platform billing is app-based, not user-based. No SCIM provisioning available in any tier.
The cost of manual management
Because there is no SCIM, every app in your GitOps stack that relies on Argo CD access requires manual provisioning and deprovisioning through ConfigMap edits or CLI commands - neither of which integrates with standard IdP lifecycle workflows.
Offboarding a local user requires three separate actions: removing the entry from argocd-cm, deleting the password hash from argocd-secret, and cleaning up orphaned RBAC policy entries in argocd-rbac-cm.
SSO users are not tracked in Argo CD at all; their access depends entirely on IdP group membership evaluated only at login time - stale permissions can persist until the next authentication event.
What IT admins are saying
Practitioners consistently flag the absence of SCIM as a gap for teams running Argo CD at scale. Common friction points include:
- Group membership from SSO is evaluated only at login, not continuously, so revoked group memberships remain active until the user re-authenticates.
- Dex and OIDC group-claim configuration is error-prone; some providers (e.g., Okta) require non-default settings to surface group claims at all.
- A known bug in Argo CD v3.x breaks RBAC group matching for SAML/OIDC groups via AWS IAM Identity Center, making group-based RBAC non-functional in affected configurations.
- The argocd admin settings rbac can CLI command misreports permissions in some v2.10.x builds, making RBAC debugging unreliable.
Common complaints:
- No SCIM support means user provisioning and deprovisioning cannot be automated via standard IdP lifecycle management; RBAC must be managed manually via ConfigMaps.
- Group membership from SSO is evaluated only at login time, not continuously; stale group memberships can persist until the user re-authenticates.
- Complex SSO and Dex configuration required for group-based RBAC; misconfiguration is a common source of permission errors.
- Removing a local user from argocd-cm leaves orphaned password hashes and token entries in argocd-secret that must be manually cleaned up.
- The argocd admin settings rbac can CLI command does not correctly report permissions in some versions (e.g., v2.10.x), making RBAC debugging unreliable.
- RBAC group matching broken in Argo CD v3.x for SAML/OIDC groups via AWS IAM Identity Center; Casbin enforcer does not iterate through groups array, making group-based RBAC non-functional in affected configurations.
- Fine-grained RBAC inheritance behavior changed between v2.x and v3.x (server.rbac.disableApplicationFineGrainedRBACInheritance parameter reported as ignored in v3.1.0), causing unexpected permission denied errors after upgrade.
- No built-in login history or last-login tracking for local users, making it difficult to identify inactive accounts.
- Official documentation primarily covers user management via the argocd CLI; declarative/automated approaches without CLI access are underdocumented.
- RBAC policy syntax (Casbin CSV) is verbose and error-prone, especially for glob pattern matching with sub-resources.
The decision
Argo CD is a strong fit for teams already managing infrastructure as code who are comfortable with Kubernetes-native tooling. The manual overhead is manageable at small scale but compounds quickly as team size grows.
Teams that need auditable, automated user lifecycle management across every app in their environment will find the ConfigMap-based model a persistent operational burden. SSO with group-based RBAC is the recommended path for enterprise use, but it requires careful Dex configuration and does not eliminate the need for manual RBAC policy maintenance in argocd-rbac-cm.
Bottom line
Argo CD's open-source model means zero licensing cost and full control, but user management is entirely manual - no SCIM, no last-login tracking, and no API-based provisioning.
Every app deployment environment that uses Argo CD for access control requires direct Kubernetes resource edits to add, modify, or remove users.
Teams with mature GitOps practices and small, stable user populations will absorb this overhead; teams with frequent onboarding/offboarding cycles or strict deprovisioning SLAs should plan for significant manual process investment or evaluate whether a managed layer like Akuity meets their operational requirements.
Automate Argo CD workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
