Why Argo CD SSO is harder than the login screen suggests
Argo CD SSO means connecting Argo CD to an identity source in one of two ways: directly to an existing OIDC provider such as Okta, Auth0, Microsoft, Keycloak or Google Workspace, or through the bundled Dex service for SAML, LDAP or GitHub connectors. Either path must also map groups to Argo CD RBAC roles and retire the built-in admin user. The login step is the easy part. If your platform team runs a working install that still depends on local accounts or the admin user, the work that matters starts after the first successful sign-in, and it should be finished before more teams and clusters depend on the instance.
The first difficulty is that RBAC mapping decides what people can change in production. A group claim that maps to a broad role can let a developer sync, delete or override applications in clusters they were never meant to touch. Update and delete permissions in Argo CD 2.14 to 3.0 now apply only to the application itself, and logs access needs an explicit logs, get permission, so the group-to-role table has to be reviewed against those rules rather than copied from an older install. Before you map anything, list which Argo CD projects, applications and clusters each group should reach, then test each mapping with a non-admin account that belongs only to that group.
The second difficulty is the claim used for mapping. Per the 3.0 upgrade notes, Dex-based RBAC now uses the federated_claims.user_id claim, so configuration that worked on 2.14 may match nothing after an upgrade. Confirm with your identity provider which claim carries group membership and whether it arrives in the token Argo CD receives. Ask the provider administrator to show a decoded token for a test user, and keep a written record of the claim name, because a silent mismatch can leave users with no access or with more access than intended.
The third difficulty is the admin user. The user management documentation recommends using the built-in admin account only for initial setup and disabling it with admin.enabled set to false once local users or SSO are configured. Disabling it too early is a lockout risk if the SSO mapping is wrong and no other administrator can sign in. Before you disable it, confirm that at least one SSO identity holds an administrative role, that you can reach the Argo CD API with a token for that identity, and that you have a documented recovery path that does not depend on the same identity provider.
The fourth difficulty is that the provider configuration is tied to the Argo CD external URL and TLS. The OIDC redirect and callback URLs must match the public address of the Argo CD server exactly, and the certificate chain must be trusted by the identity provider and the browser. Changing the hostname, moving to a new ingress or rotating the certificate can break sign-in for every user at once. Agree the final URL and certificate arrangement before configuring SSO, and plan any change to them as a coordinated maintenance step.
Which Argo CD settings and components SSO touches
SSO for Argo CD is spread across a few places: a bundled identity broker or a direct OIDC connection, the RBAC policy that turns identity into permissions, the local admin switch, and the Kubernetes Secrets that hold client credentials. Each card below names one of these so you can confirm what your version expects before you change anything.
Bundled Dex service and connectors
Dex is the identity broker bundled with Argo CD. It is the route for SAML, LDAP or GitHub sign-in, and it runs as its own workload in the Argo CD namespace. Check which connectors are enabled, whether the Dex pod is healthy after changes, and that the redirect URL registered with each upstream provider matches the Argo CD URL exactly.
Direct OIDC provider settings
If your identity provider speaks OIDC directly, such as Okta, Auth0, Microsoft, Keycloak or Google Workspace, Argo CD can connect without Dex. The settings define the issuer, client ID, requested scopes and the claim that carries group membership. Confirm the exact configuration keys against the user management documentation for the version you run, because key names have changed across releases.
RBAC policy and group mapping
The RBAC policy maps groups or claims from your identity provider to Argo CD roles and project permissions. Mistakes here usually fail open or closed without a clear error, so test each mapping with a user from each group. For 3.0 and later, the upgrade notes move Dex-based RBAC to the federated_claims.user_id claim. Confirm which claim your identity path emits before you edit the policy.
The admin.enabled switch
The built-in admin account is controlled by the admin.enabled setting. Argo CD's user management documentation recommends keeping it only for initial setup and disabling it with admin.enabled set to false once local users or SSO work. Before you disable it, confirm that at least one SSO user holds an administrator role and that someone can recover access through the Kubernetes API if the identity provider is unavailable.
Local user accounts
Local accounts are defined in Argo CD configuration and can be used alongside SSO for break-glass or service access. Each account needs a deliberate purpose, a role and a password or token policy. Review the list during the SSO cutover and remove any account that is no longer needed, since local accounts bypass your identity provider's sign-in controls such as multi-factor authentication.
Kubernetes Secrets for client credentials
OIDC client secrets and connector credentials are stored in Kubernetes Secrets rather than in plain configuration. Check who can read those Secrets through RBAC, whether they are encrypted at rest in your cluster, and how rotation is handled. Argo CD redacts OAuth2 credentials from API responses and logs, but that protection does not extend to anyone with direct read access to the Secret objects.
Choosing between direct OIDC and bundled Dex
This table compares connecting Argo CD straight to an existing OIDC provider with running the bundled Dex component for SAML, LDAP or GitHub sources. Read each row against your directory, your group model and who will own the Dex configuration after handover.
| Decision point | Direct OIDC to your provider | Bundled Dex with SAML, LDAP or GitHub |
|---|---|---|
| When it fits | Your provider already speaks OIDC (for example Okta, Auth0, Microsoft, Keycloak or Google Workspace) and emits group claims Argo CD can map to RBAC roles | Your identity source is SAML-only, LDAP-only or GitHub-based, or you need a connector that your OIDC provider does not offer to Argo CD |
| Configuration surface | One OIDC client in the identity provider and one oidc.config block in Argo CD, with the client secret stored in a Kubernetes Secret | Dex connector settings in Argo CD configuration, plus the upstream application registration or bind account for each connector |
| Who owns the component | Your identity team owns the provider client and claim configuration, and your platform team owns Argo CD RBAC mappings | Your platform team owns Dex upgrades, connector settings and troubleshooting, so plan for that ownership before handover |
| Group claims | Groups arrive as a claim on the token, so confirm the claim name, whether it is emitted for all users and how nested groups are represented | Groups come from the connector, and RBAC keys on the federated_claims.user_id claim in 3.0 and later, so test which claim each connector emits |
| Testing connector or client changes | Test in a non-production Argo CD instance with a test user in each RBAC group before changing production sign-in | Test each connector change in a separate instance, verify login and group mapping for every connector, then roll forward with a documented rollback |
| Upgrade effect | Argo CD minor upgrades affect only the OIDC settings you configured, so regression tests focus on login and RBAC | Dex changes travel with Argo CD releases, so each minor upgrade needs connector login tests in addition to RBAC tests |
| Brokered provider such as Keycloak | Not needed for a single source. Adding a broker centralizes sources but adds another system to patch, back up and secure | Often the cleaner choice when several sources (SAML, LDAP, social) must be combined, because the broker presents one OIDC endpoint to Argo CD |
| Local accounts for break-glass | Keep the built-in admin disabled once SSO works and document one or more named local accounts with restricted RBAC and a tested recovery procedure | Same approach: disable admin.enabled after SSO is verified and keep a tightly controlled local account so an identity outage does not lock out operators |
How to build Argo CD SSO in order
This sequence connects Argo CD to your identity provider, maps identity groups to roles, and proves each access boundary before the local admin user is retired. Each step closes with a check you can observe in the UI or CLI, so a failure is found before it reaches production users.
Confirm the Argo CD minor version
The platform engineer records the exact minor version you will run and checks it against the release cadence, since only the three most recent minor versions receive patch releases. The supplied release information lists v3.5.5, v3.4.11 and v3.3.16 as the latest patches, with v3.6.0 in release candidate, so confirm current status on the release page before you pin. Read the upgrade notes for your version, especially how RBAC applies to update and delete actions and which claim Dex-based RBAC reads. Check: the saved output of the argocd version command matches the pinned version, and a written list of RBAC behaviors has been tested in a non-production instance.
Set the external URL and TLS
Set the external URL in the argocd-cm ConfigMap and serve Argo CD over TLS on a hostname your identity provider can reach. The login redirect is built from this URL, so a mismatch between the configured URL, the ingress hostname and the certificate causes login failures that look like identity problems. Confirm the certificate chain is trusted by browsers and by the components that call the identity provider. Check: the Argo CD login page loads on the final hostname with a valid certificate, and the SSO redirect in the browser address bar points to the expected host.
Register the Argo CD client with the provider
Create an OIDC client in your identity provider using the exact redirect URI from the previous step. Agree with the identity team which claim carries group membership, its name and its format, and whether groups come from the token or from a directory lookup. Store the client secret in your secrets management system, not in a shared document or chat. Check: a test token issued to a sample user shows the expected audience and a groups claim containing the exact group names you plan to map.
Configure direct OIDC or the Dex connector
Choose one path. Direct OIDC configuration in argocd-cm fits providers that already speak OIDC, such as Okta, Auth0, Microsoft, Keycloak or Google Workspace. The bundled Dex with a connector fits SAML, LDAP or GitHub sources, but it adds a component you must run, patch and monitor. Reference the client secret through a Kubernetes Secret rather than embedding it in configuration. Check: the SSO login option appears on the login page, and a test user completes sign-in and lands in the UI under their own identity.
Map groups to roles in the RBAC policy
Write the policy in the argocd-rbac-cm ConfigMap. Map groups that need broad access to a built-in role, and map team groups to permissions scoped to their own AppProject. Set the default policy to no access so unmapped identities receive nothing. Confirm the claim key in the policy matches the claim agreed in the registration step, and for Dex-based RBAC use the federated_claims.user_id claim named in the 3.0 upgrade notes. Check: argocd account can-i returns the expected answers for a sample subject in each group, and the project role listing matches the design.
Test login with non-admin accounts
Use one non-admin test account per mapped group and sign in through SSO for each. Confirm the Applications view shows only the projects the mapping grants, then perform one allowed action, such as a sync in the owning project. Record the result for each group in a short test log. Check: each test account sees its expected projects in both the UI and the CLI, and the allowed sync completes. If a group sees too much or too little, correct the policy and repeat this step before continuing.
Confirm denial for unmapped users
Sign in with an account that belongs to no mapped group, then attempt to view, sync and delete an application in a project owned by another team. Repeat the attempts from the CLI using a token issued to that account. Also confirm that a read-only group cannot delete resources. Check: every attempt returns a permission denied result, and the Argo CD logs or your audit pipeline record the attempts. Do not move on until each case in the test log has been observed as denied.
Disable admin and document break-glass
Only after the login and denial tests pass, set admin.enabled to false in argocd-cm, as the user management documentation recommends once SSO is configured. Before making the change, write the break-glass path: who may use it, where the recovery credentials or procedure are held, how it is activated, and how each use is logged and reviewed. Test the procedure in a non-production environment where possible. Check: the local admin login is refused in the UI and CLI, an SSO administrator still signs in, and the break-glass document has been reviewed by named owners.
How to test SSO before you retire the admin user
Do not set admin.enabled to false until a written test plan shows that SSO works for every group, rejects everyone else, and leaves you a way back in. The user management documentation recommends the built-in admin user only for initial setup, so retiring it is the last step, not the first. Build the plan as a matrix with one test account per mapped group, one account with no group mapping, and one account that was removed from a group during the test. Record the expected result for each cell before you run anything, then record what actually happened, including the time and the Argo CD version under test.
Role tests need to go beyond login. For each group, sign in through the web UI and confirm the user sees and syncs only the applications in the projects that group is allowed to reach. Use a project without elevated rights for the main check. Since the 2.14 to 3.0 changes, update and delete RBAC applies only to the application itself, so test that a user with update rights on one application cannot change project-level settings. Logs access is a separate permission: a role needs an explicit logs, get rule, so test a group with and without it. In 3.0, Dex-based RBAC matches on the federated_claims.user_id claim, so confirm that the value in each policy entry matches what your identity provider actually sends.
The fail-safe checks come before the admin user is disabled. First, confirm a break-glass path exists: a documented account or kubeconfig route held by the platform team, tested end to end, and stored where the on-call engineer can reach it during an identity outage. Second, remove a test user from a mapped group in the identity provider, then confirm access ends at the next login or token refresh and that existing sessions do not keep elevated rights. Third, make the identity provider unreachable in a test environment and observe what happens to logins and to sessions already in progress. Write down who can recover access in that state and how long your own change process takes to act, because the provider's availability becomes your availability.
Test the command-line interface and the API along with the web UI. Argo CD authenticates API requests only with JSON Web Tokens, so a team that tests only the browser can miss a token path that still works after the admin user is gone. Log in with the CLI through SSO, run a read and a sync on a permitted application, and make the same calls directly against the API with a token. Then repeat the calls with an expired token, a token from a removed user, and no token at all. Each should fail in the expected way. Also check logout: confirm what the web UI clears, and confirm with the vendor documentation whether tokens already issued remain valid until they expire. Keep the resulting evidence, dated and tied to the version under test, for your access review.
What drives the effort and cost of Argo CD SSO
This table lists the factors that change how much work an Argo CD SSO integration takes and who pays for that work. Read each row as a lever: the driver on the left grows effort when left unmanaged, and the right-hand column shows how to keep it contained. The main takeaway is that identity provider access and group hygiene usually matter more than the Argo CD configuration itself.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Identity sources and protocol | Each source (OIDC, SAML, LDAP or GitHub) adds connector setup, claim testing and a separate troubleshooting path. Bundled Dex connectors are configured by DeployOpen or your team, while an existing OIDC provider is usually a direct configuration. | Standardize on one OIDC provider where possible. Confirm with your identity team which protocol your directory already supports before choosing Dex connectors. |
| Group count and directory cleanliness | Argo CD maps directory groups to RBAC roles, so messy, nested or unowned groups mean more mapping decisions and more review time. Cleanup is usually done by your identity team or a directory administrator. | Clean up and name groups before mapping. Map only groups that have a documented owner and a clear purpose for Argo CD access. |
| Argo CD instances and clusters sharing one login | Each instance or cluster sharing a login needs its own redirect configuration, group-to-role mapping and testing. Shared login multiplies verification work even when the code is identical. | Start with one instance and one cluster for the SSO pattern, then reuse the tested configuration. Confirm with your platform team whether instances must share one identity provider client. |
| Brokered identity provider | Placing a broker such as Dex or a central federation service between Argo CD and the directory adds a component to configure, patch and monitor. Who operates the broker determines who carries its upgrade and support cost. | Decide up front whether the broker is required. If it is not needed for a single OIDC provider, skip it and reduce the number of moving parts. |
| Access to identity provider administrators and change control | Client registration, claim mapping and group changes need administrators of the identity provider. Waiting for their change windows often sets the schedule more than the Argo CD work does. | Agree on access, a named contact and a change process before the project starts. Ask for a test tenant or test client if your identity provider offers one. |
| RBAC design depth across projects | Each Argo CD project and role needs a decision about who can sync, delete or read logs. Deep role models across many projects take longer to design, review and test than a small starting set. | Limit role design to a small set of projects first. Expand only after the first roles are tested and reviewed by the application owners. |
| Testing and compliance evidence | Assessors and internal reviewers may expect records of login tests, role tests, admin user disablement and access reviews. Producing that evidence is extra work, and DeployOpen prepares evidence but does not issue audit opinions. | Ask your auditor or compliance lead which evidence they expect before testing starts. Build test cases that produce the records once, instead of recreating them later. |
Securing SSO and identity in Argo CD
Once Argo CD trusts an identity provider, the identity layer decides who can deploy to which clusters. The cards below cover the identity-specific controls to set and verify, from disabling the local admin user to restricting who can change SSO and RBAC configuration. Repo-server risks and project boundaries are covered in the security hardening topic.
Disable the admin user
The user management documentation recommends using the built-in admin user only for initial setup and disabling it by setting admin.enabled to false once SSO or local users work. Before disabling it, confirm that at least one SSO user holds a cluster-admin-equivalent role in Argo CD. Document the break-glass procedure separately, including who can re-enable admin, where its credentials are held, and how that event is recorded.
Restrict edits to RBAC and SSO config
Changes to argocd-rbac-cm and to the Dex or OIDC settings can grant write access or redirect logins, so they are high-impact. Limit edit rights on these ConfigMaps and Secrets to a small platform group, and route changes through Git or a reviewed change process. Confirm which Kubernetes RBAC roles in the Argo CD namespace can read or patch them, since namespace access can expose the same settings.
Protect and rotate client secrets
The OIDC client secret and any Dex connector secrets live in Kubernetes Secrets. Restrict read access to those Secrets with namespace RBAC, avoid copying them into Git in plain form, and use an external secret store if your policy requires it. Define a rotation schedule with the identity provider team and test that a rotated secret is picked up by Argo CD and Dex before the old one is revoked.
Enforce TLS on identity endpoints
Serve the Argo CD external URL over TLS and confirm that the redirect URI registered with the identity provider uses the same HTTPS address. Verify that every OIDC issuer, Dex connector and LDAP or SAML endpoint the server calls is reached over TLS with certificates your trust store validates. Check certificate expiry and the CA bundle used by Dex, because a broken chain typically surfaces as failed logins.
Rely on JWT and credential redaction
The security documentation states that API requests authenticate only with JSON Web Tokens and that cluster, Git and OAuth2 credentials are redacted from API responses and logs. Treat these as documented behavior to verify in your version, not as assumptions. Test a token from a logged-out or revoked user, confirm that a sample API response does not show credentials, and review log shipping to see whether any upstream component captures more than Argo CD does.
Limit default policy for new users
Users who sign in through SSO receive the policy defined by policy.default in argocd-rbac-cm, and group mappings add roles on top of it. Set the default to read-only or no access, then grant write permissions only through explicit group-to-role bindings. Test with a newly provisioned account in a non-production instance to confirm that it cannot sync, delete or change applications before you rely on the mapping.
How SSO differs by deployment model
A single-node or non-HA install is the simplest shape: one Argo CD server, one Dex pod if you use the bundled Dex, and no replica spread. The SSO settings are the same as in other shapes, but the impact of a mistake is larger because a restart or failed upgrade stops every login at once. Plan the change in a window where you can recover quickly.
- Redirect URL: Set the external URL to the hostname users type in the browser, and register the matching callback in the identity provider. A mismatch here is the most common first-login failure.
- Certificate trust: If the identity provider uses a private certificate, load the internal CA into the Argo CD and Dex trust configuration, restart, and confirm the chain from the Argo CD pod.
- Dex or OIDC placement: Run the bundled Dex in the same cluster, or connect to an existing OIDC provider directly and skip Dex.
- Testing: Sign in with a non-admin user, confirm group claims map to the intended roles, and disable the admin user only after a second SSO administrator has signed in successfully.
Confirm the settings keys, callback path and Dex restart behavior in the vendor documentation for the version you run, because these details have changed between minor releases.
The high availability manifests need at least three nodes because of pod anti-affinity rules, so SSO planning starts with capacity. Argo CD keeps its state in Kubernetes objects, and Redis is a disposable cache, which means a login session can depend on any replica. The identity configuration must therefore be identical on every replica that handles sign-in or token validation.
- Redirect URL: Keep one public hostname that resolves to the load balancer or ingress. Confirm that the ingress presents the same host and certificate in front of all replicas.
- Certificate trust: Mount the CA bundle for every component that talks to the identity provider. A certificate rotation usually needs a rolling restart, so schedule it.
- Dex or OIDC placement: Confirm in the HA documentation whether Dex runs with multiple replicas in your manifests, and decide whether a direct OIDC connection removes one component from the failure path.
- Testing: Sign in, drain one node, restart the server pods, and confirm that existing sessions and new logins still work. Repeat the group-to-role check after each restart.
Review the high availability and security documentation for the version in use, and confirm how sessions, JSON Web Token signing keys and Dex replicas behave during a rolling upgrade before you rely on them.
In a multi-cluster design, Argo CD runs in a management cluster and deploys to clusters it does not run in. Users sign in only to the central instance, so SSO is configured once, but the identity provider must be reachable from the management cluster. Target clusters are registered with their own cluster credentials, which is a separate path from user sign-in and must be planned separately.
- Redirect URL: Use one hostname for the central instance. Do not create a redirect for each target cluster, because target clusters do not host the login flow.
- Certificate trust: Trust is needed only in the management cluster for the identity provider. Confirm how cluster registration credentials are stored and rotated, since they are separate from SSO certificates.
- Dex or OIDC placement: Place Dex or the direct OIDC connection in the management cluster. Map groups to projects so a team's access is limited to the clusters and namespaces it owns.
- Testing: For each team, verify that the user can deploy to its permitted clusters and is denied on a different cluster. Include a user who belongs to no group.
Before go-live, confirm in the user management documentation for your version how project and RBAC rules apply across registered clusters, and treat the policy file as code that goes through review.
In an air-gapped or private-network install, the identity provider must be reachable from inside the boundary, and every SSO dependency must be available without the public internet. The choice of identity source narrows early. Connectors that call an external service may not work at all, so confirm the connector list for your version before you choose SAML, LDAP or a direct OIDC provider.
- Redirect URL: Use an internal DNS name that resolves inside the network, and make sure users' browsers can reach both the Argo CD host and the identity provider.
- Certificate trust: Distribute the internal CA chain to Argo CD and any Dex component. Private certificate chains are the most frequent cause of token validation errors in isolated environments.
- Dex or OIDC placement: Prefer an internal identity provider with a direct OIDC or SAML path, and mirror any Dex images or dependencies into your registry so upgrades do not need outbound access.
- Testing: Test from a client inside the boundary, under the same network policies that production uses, and confirm that failed token refresh and provider outages produce clear errors.
Confirm in the vendor documentation which Dex connectors and token flows work without outbound access for your version, and record the mirrored image versions alongside the SSO configuration so the next upgrade can be tested the same way.
What to monitor, back up and document after SSO goes live
Once SSO is live, the ongoing work is watching for denied access, reviewing every change to who can do what, and keeping a current record of the identity setup. Argo CD writes authentication and authorization events to the argocd-server logs, and Kubernetes records related events on the cluster. Forward both to your central logging platform and alert on unusual spikes in failed logins or authorization denials. Also confirm that the people who investigate have the explicit logs, get permission that Argo CD 3.0 requires for log access, so the monitoring works for the team that needs it.
Group membership and RBAC policy should change only through a reviewed path. The group-to-role mapping lives in the argocd-rbac-cm ConfigMap, so keep it in version control and deploy it through the same review process as other cluster configuration. Membership changes happen in your identity provider, so assign an owner who reviews group changes that grant access to production projects. Argo CD also keeps its state in Kubernetes objects, including Application and AppProject resources, repository and cluster credentials stored as Secrets, and the argocd-cm and argocd-secret objects. Back these up with your normal cluster tooling and run a restore test into a separate cluster. Treat Redis as a disposable cache: plan to rebuild it after a failure instead of backing it up.
Documentation is what lets someone other than the original builder recover access. Record the connector or OIDC settings, including the issuer, client registration owner and claim names, along with the group-to-role map and the project each group can reach. Name the owner of each identity source, such as the workforce directory, the Dex connector or a separate OIDC provider. Write a break-glass procedure before you disable the built-in admin user, which the user management documentation recommends once SSO or local users are configured by setting admin.enabled to false. Decide who may use the emergency path, where its credentials are stored, how it is tested, and how each use is logged and reviewed afterward.
Upgrades can break login and access even when the cluster itself is healthy. Argo CD ships a minor release four times a year, and only the three most recent minor versions receive patch releases, so plan a minor upgrade on that cadence and re-test login and RBAC after each one. Argo CD 3.0 changed RBAC claim handling for Dex-based setups, which now uses the federated_claims.user_id claim, so review group mappings and test them during any 2.14 to 3.0 move. Update and delete permissions now apply only to the application itself. Before you commit to an upgrade window, confirm with your support provider which versions they cover and what the test plan includes.
Questions teams ask before building Argo CD SSO
How much does Argo CD SSO setup cost?
Cost depends on the scope agreed in writing, and DeployOpen does not publish a price list. The main drivers are the number of identity providers and connectors involved, whether you connect directly over OIDC or through bundled Dex, how many groups must map to RBAC roles, and how many environments need a test pass before production. Argo CD is released under the Apache License 2.0, so the project itself charges nothing for the software. Costs split into one-time work (design, configuration, testing and cutover) and recurring work (upgrades across quarterly minor releases, group changes, and identity provider secret or certificate rotation). When you ask for a quote, request that these items appear separately, that each step names who performs it, and that the identity provider administrator tasks on your side are listed.
How long does an Argo CD SSO integration take?
The useful answer is a sequence of steps and dependencies, and the calendar time depends on how quickly each dependency clears. Work starts by agreeing the identity provider, the connector or OIDC client, and the group names that will map to roles. The identity provider administrator then creates the application or connector registration and returns the client details. Configuration in Argo CD follows, then a test plan runs with named users in each group, followed by change approval and a cutover window in which the local admin user is disabled. Each handoff to an external administrator can add elapsed time. Ask for a schedule that names each dependency and the person responsible for clearing it.
What do we need from our team before SSO work starts?
Before work starts, you need four things ready. First, identity provider administrators who can create an application or connector registration, set redirect URIs and release group claims. Second, agreed group definitions that map to Argo CD roles, such as read-only users, deployers for each project, and cluster administrators. Third, a test plan with named test users for each role, including a negative test that confirms a user outside the groups is denied access. Fourth, a change approval path, because switching the login method and disabling admin affects everyone who deploys. Also confirm who holds the Kubernetes access needed to edit the Argo CD ConfigMaps and the admin secret during cutover.
Can our internal platform team set up Argo CD SSO alone?
Often yes, if the team already runs Kubernetes and holds administrative access to both the identity provider and the Argo CD namespace. The configuration in Argo CD is modest, but the risk sits in the surrounding steps: correct redirect URIs, group claims that actually arrive in tokens, and a tested fallback before admin is turned off. Check three things honestly. Does someone on the team have identity provider administration rights? Is there a second person to review the RBAC policy? Does a non-production Argo CD exist where the cutover can be rehearsed? If any answer is no, a fixed-scope engagement can cover the gap. Also plan for the upgrade cycle, since Argo CD ships a minor release four times a year and only the three most recent minors receive patches.
Should we use direct OIDC or Dex for Argo CD?
Use direct OIDC when your identity provider already supports OpenID Connect and you want fewer components to run. Use Dex when you need a connector such as SAML, LDAP or GitHub that your provider does not offer directly. Argo CD supports SSO through its bundled Dex or directly through an existing OIDC provider such as Okta, Auth0, Microsoft, Keycloak or Google Workspace. Dex adds a layer to run, upgrade and test, including how it handles groups and claims. Direct OIDC keeps the group path shorter but depends on your provider emitting group values in the token. Confirm the claim behavior in the Argo CD user management documentation and in your provider's own documentation before you choose.
What happens if we disable the admin user too early?
If admin is disabled before SSO sign-in and an RBAC mapping are verified, you can lose the only built-in way to sign in and correct the configuration. Recovery then depends on Kubernetes-level access to reset settings. The Argo CD user management documentation recommends using admin only for initial setup and disabling it with admin.enabled set to false once local users or SSO are configured. Before that switch, confirm that a named SSO user in the administrator group can sign in, create and sync an application, and that a second administrator can do the same. Keep a documented break-glass procedure that uses Kubernetes access, and rehearse it in a non-production instance first.
What changes when upgrading Argo CD across the 3.0 RBAC claim change?
Upgrading from 2.14 to 3.0 changes who can do what, so an SSO policy that worked before can deny access afterward. Update and delete RBAC now apply only to the application itself, and viewing logs needs an explicit logs, get permission. Annotation-based resource tracking is the default. For Dex-based RBAC, the 3.0 upgrade notes say the claim used for mapping is federated_claims.user_id, so policies written against the previous claim need review. Repository configuration also moved out of argocd-cm, so repositories must be defined as Kubernetes Secrets. Test each role in staging, read the upgrade notes line by line, and confirm the claim value your provider emits with a test login before production.
How DeployOpen scopes, builds and hands over Argo CD SSO
DeployOpen connects Argo CD to your identity provider, either directly through an existing OIDC provider or through the bundled Dex for SAML, LDAP or GitHub. The work is planned as a fixed-scope engagement with a written scope, then delivered inside your own clusters and identity tenant, and handed over with documentation your team can run.
How we scope
- Confirm which identity provider you use and whether Argo CD should federate with it directly over OIDC or through bundled Dex.
- Inventory the groups that need Argo CD roles and agree how each group maps to read, sync and admin permissions.
- Record in the written scope which clusters, Argo CD instances and user populations are covered before any work starts.
How we build
- Configure the OIDC client or Dex connector in a non-production Argo CD instance and test login with a representative set of users.
- Map identity provider groups to Argo CD RBAC policy, using the claims your provider actually issues, and test allow and deny cases.
- Verify that API tokens, sync and log permissions behave as the scope describes, then disable the built-in admin user once SSO is confirmed.
How we hand over
- Deliver the configuration, group mapping table and RBAC policy as versioned files kept in your own Git repository.
- Document the break-glass procedure, the steps to recover access if the identity provider is unavailable, and who holds that access.
- Walk your identity and platform engineers through login troubleshooting, group changes and how to review RBAC drift.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover SSO changes after the handover.
- Plan re-testing of login and RBAC after each Argo CD minor upgrade, since the 3.0 notes changed Dex-based RBAC claims.
- Confirm with your identity provider vendor and your own environment which claims, token lifetimes and group features apply to your tenant.
