How authentik sign-in for Argo CD works and what it changes for GitOps teams
Argo CD sits on the delivery path to every cluster it manages, so a shared admin login there is a risk that every GitOps team inherits. The platform team should replace it with named, SSO-based access in which authentik group membership decides who can sync, override or delete applications. Argo CD supports this in two ways: its OIDC settings pointed directly at authentik, or its bundled Dex connected to authentik as an upstream OIDC connector. Both paths are configured on two sides, the authentik OAuth2/OIDC provider and application and the Argo CD settings, so the work is split between the identity and the cluster administrators. Argo CD is released under the Apache License 2.0 with no paid edition from the project itself, and authentik's Open Source edition is MIT licensed, so neither product adds a license cost to this design.
Before choosing the path, confirm with your own Argo CD version which SSO settings it uses, since the RBAC claim handling changed in the 3.0 line. The Argo CD 3.0 upgrade notes say Dex-based RBAC now uses the federated_claims.user_id claim, which matters if group or user matching in argocd-rbac-cm depends on the claim your authentik provider emits. Decide early whether the local admin account will be disabled with admin.enabled set to false once SSO works, and who holds break-glass access if the identity provider is unavailable. Also decide which authentik groups map to which Argo CD roles, because that mapping is the control that determines whether a team can change production applications or only view them.
Two consequences should be planned before the first login. Users who previously used a shared account will need their own identities and group memberships in authentik, so the source of those groups (manual, directory sync or provisioning) becomes a dependency of Argo CD access. Changes to group membership in authentik take effect in Argo CD at the user's next login or token refresh, so removing someone from a group is not an instant revocation of cluster-level actions they already started. Review the Argo CD user management documentation alongside your authentik provider settings before you fix the group mapping.
What you need before connecting Argo CD to authentik
Connecting Argo CD to authentik touches three systems: the Argo CD version you run, the authentik deployment that issues tokens, and the Kubernetes cluster that hosts Argo CD. Settle each of the items below before you create any OIDC client, because redirect URIs, certificate trust and the admin account plan all depend on them.
Argo CD version line
Target a patch release on a minor line Argo CD still maintains. As of October 12, 2026, the project published patch releases v3.5.5 (marked latest), v3.4.11 and v3.3.16, with v3.6.0 in release candidate. Only the three most recent minor versions receive patches, so a 2.x cluster should be upgraded through the documented 2.14 to 3.0 steps before SSO work. Confirm the version on your cluster against the releases page before you copy any configuration.
Supported authentik version
Run authentik on a version the project still patches. The security policy lists 2026.5.x and 2026.8.x as the supported lines, and security releases are announced at least 24 hours in advance. Plan your maintenance window around that notice. Because authentik upgrades must be applied in order, record your current version and confirm the upgrade path before you add an OAuth2/OIDC provider for Argo CD.
Public HTTPS hostnames
Argo CD and authentik each need a stable HTTPS hostname that users reach from their browsers. The authentik issuer URL and the Argo CD external URL become part of the OIDC configuration, so changing either later means updating the provider's redirect URI and the Argo CD settings together. Decide these names first and keep them consistent across staging and production.
DNS and certificate trust
Argo CD must reach the authentik issuer endpoint to fetch its discovery document and signing keys, and the browser must trust both certificates. If authentik uses an internal certificate authority, Argo CD needs that CA in its trust store. Confirm name resolution from inside the cluster, not only from your workstation, because the Argo CD pods resolve names independently.
Kubernetes cluster for Argo CD
Argo CD runs on a Kubernetes cluster you control, and its SSO settings live in the cluster as ConfigMaps and Secrets. Confirm that you can edit the argocd-cm and argocd-rbac-cm objects and manage the client secret through your normal secret process. If you plan the high availability manifests, the project documents a minimum of three nodes because of pod anti-affinity rules.
Admin account plan
Decide before cutover how you will sign in if SSO fails. The user management guidance recommends keeping the built-in admin user only for initial setup and disabling it with admin.enabled set to false once SSO works. Record who holds the initial admin password, where it is stored, and which named administrator accounts will hold the admin role through authentik groups, so that a broken OIDC setting does not lock out the platform team.
Enterprise features you can skip
This integration uses the open source OAuth2/OIDC provider and group claims, so the Enterprise-only features are not required. Google Workspace and Microsoft Entra ID integrations, mTLS, privileged access management, password history, enhanced audit logging and Enterprise Plus support do not change how Argo CD signs users in. Confirm your authentik edition and license terms with your procurement team, since the enterprise directory carries a separate license.
Direct OIDC or Dex: which path fits your Argo CD setup
With the direct path, Argo CD's own OIDC settings point at authentik as the OpenID Connect provider. Argo CD sends users to authentik's authorization endpoint, receives an ID token back, and reads the claims it needs from that token without an intermediate broker. The result is one fewer component to run, one fewer configuration surface to review, and a shorter path when you troubleshoot a failed login. You register Argo CD as an OAuth2/OIDC provider application in authentik, set the issuer URL, client ID and client secret in the Argo CD configuration, and then map authentik groups to Argo CD roles.
- Fewer moving parts: There is no Dex deployment to size, upgrade or monitor alongside the Argo CD API server.
- Group claims come from the token: The groups claim in the ID token drives RBAC, so the scope mapping in authentik determines what Argo CD sees.
- Clear failure domain: A login problem usually points to the authentik provider, the redirect URI or the client secret.
- Limited connector choice: You depend on the OIDC behavior of authentik rather than on Dex connectors, which suits a single identity source.
- Ask your team: Confirm which claim names your Argo CD version reads for groups in the user management documentation.
Before you commit, confirm that your Argo CD version and your authentik release both support the group claim layout you intend to use, and test one group mapping end to end.
With the Dex path, Argo CD keeps its bundled Dex as the login broker and Dex connects to authentik as an OIDC upstream. Users authenticate with Dex, Dex authenticates with authentik, and Dex passes the resulting identity and claims to Argo CD. This layer is useful when you want Argo CD to offer several login sources through one place, or when your existing Argo CD configuration already uses Dex connectors. The cost is an extra component whose connector settings, claim handling and upgrade behavior you must own.
- Broker in the middle: Dex handles the upstream OIDC handshake, so Argo CD sees the identity Dex issues.
- Connector configuration: The authentik connector lives in the Dex settings, which is a second place to check when groups do not arrive.
- Multiple sources possible: Dex can offer more than one connector if you need a fallback during a migration.
- Extra upgrade surface: Dex versions move with Argo CD releases, so plan a test login after each upgrade.
- Confirm connector behavior: Check the current Dex connector documentation for your Argo CD version before you rely on group forwarding.
If your organization needs multiple login sources or already runs Dex, this path can be the better fit, provided your team is ready to operate the extra layer.
Group handling decides who can sync, override or delete applications in Argo CD, so it is the part of the design that needs the most care. On the direct path, Argo CD reads group membership from the claims in the OIDC token that authentik issues, and the scope mapping you attach to the provider controls which groups appear. On the Dex path, Dex reads the upstream claims, decides which identity to pass on, and then Argo CD evaluates the RBAC rules against what Dex forwards. A group that exists in authentik but never reaches Argo CD in the token will not grant access, however correct the RBAC policy looks.
- Token-side mapping on the direct path: Confirm that the groups claim is present in the ID token for a test user before writing any RBAC rules.
- Upstream and forwarded claims on the Dex path: Verify both the claim Dex receives from authentik and the claim Dex forwards to Argo CD.
- Group names must match exactly: Case, prefixes and separators are a common source of silent denials.
- Keep a test account per role: One account for each intended role makes it easy to prove that a mapping works.
- Ask for a token sample: Request a redacted decoded token from a test login as part of acceptance.
Review the group claim path in the Argo CD user management documentation for your version before you map production groups.
Argo CD 3.0 changed how Dex-based RBAC identifies users. According to the upgrade notes for the 2.14 to 3.0 path, Dex-based RBAC now uses the federated_claims.user_id claim. Setups that wrote RBAC rules against an earlier identifier can see users lose access or match the wrong subject after the upgrade. The change affects how RBAC subjects are written, so it matters most for teams that migrated from Argo CD 2.x with existing Dex connectors and policies already in place.
- Identifier change: RBAC subjects written for the old identifier need to be reviewed against federated_claims.user_id.
- Test before cutover: Run a login as a known user on a staging instance and check the effective role.
- Review the upgrade notes: The 2.14 to 3.0 upgrade notes also change update and delete RBAC, logs access and resource tracking defaults, so review them together.
- Direct OIDC is not exempt from RBAC review: Your policy file still needs group checks on the direct path, even though the Dex identifier change does not apply to it.
- Ask your vendor or partner: Request a before and after RBAC comparison as part of the migration plan.
If you are on a version earlier than 3.0, plan this review as part of the upgrade rather than as a separate task later.
The right path depends on how many login sources you need, how much operational surface your platform team will accept, and whether your Argo CD estate already relies on Dex. A useful decision test is to ask whether you need anything beyond authentik as the identity source. If you do not, the direct path keeps the design smaller. If you do, or if your current installation already depends on Dex connectors, the Dex path avoids a redesign. In either case, the decision should be recorded alongside the Argo CD version, the authentik release and the group names that will be mapped.
- Single source of login: Choose the direct path when authentik is the only identity source for Argo CD.
- Existing Dex connectors: Choose the Dex path when your installation already depends on them.
- Version record: Note the Argo CD and authentik versions used during testing, since both change over time.
- Admin account: Keep the built-in admin user only for initial setup and disable it with admin.enabled set to false once SSO works.
- Confirm with documentation: Verify current OIDC and Dex connector settings in the Argo CD user management documentation for your version.
Before you go live, confirm that a non-admin user can log in, that each mapped group produces the expected role, and that a user removed from an authentik group loses access in Argo CD.
How to configure the authentik provider and Argo CD settings in sequence
This sequence connects Argo CD to authentik over OIDC, maps authentik groups to Argo CD roles, and ends with a verified non-admin login and a disabled local admin account.
Create the authentik OIDC provider and application
An authentik administrator creates an OAuth2/OIDC provider and an application that points to it, then registers the Argo CD callback URL as the redirect URI. Use the Argo CD address your users open in the browser, followed by the callback path defined in the Argo CD user management documentation, and confirm the exact path against that page before saving. Record the client ID and client secret for the next step. The step is done when the application appears in the authentik application list and the provider shows the expected redirect URI and issuer URL.
Set scopes and a groups claim
In the provider, confirm that the openid, profile, email and groups scopes are available, and add a property mapping that places the user's authentik group names into a groups claim in the ID token. Argo CD reads that claim to make RBAC decisions, so the claim name must match what the RBAC policy will reference. Confirm the claim with a test token or with the authentik preview for a test user. The step is done when the decoded ID token for a test user lists the expected group names under the groups claim.
Store the client secret in a Kubernetes Secret
A platform engineer creates a Kubernetes Secret in the Argo CD namespace that holds the OIDC client secret, and references it from the Argo CD configuration rather than writing the value into a ConfigMap. Choose either the direct OIDC settings or the bundled Dex settings, based on whether your team wants Argo CD to talk to authentik directly or through Dex, and set the issuer, client ID and requested scopes accordingly. The step is done when the Secret exists, the Argo CD settings reference it by name, and the Argo CD API server starts without configuration errors in its logs.
Map authentik groups to Argo CD RBAC roles
Edit the Argo CD RBAC policy so that each authentik group maps to a role with the permissions that team needs, such as read-only access to applications in a project or sync rights for a platform team. Set the default policy to no access so that users without a mapped group see nothing. If you use Dex, confirm the RBAC subject format against the Argo CD 3.0 upgrade notes, since Dex-based RBAC there uses the federated_claims.user_id claim. The step is done when the policy file validates and the argocd admin tooling or the Argo CD settings page shows the expected role for a test group.
Test login with a non-admin user
Sign in to Argo CD from a browser as a user who belongs only to a non-admin group, not as the local admin. Confirm that the sign-in redirects to authentik, returns to Argo CD, and that the user sees only the applications and actions the group's role allows. Repeat with a second group if you use more than one role. Check the Argo CD API server logs for authentication errors. The step is done when each test user lands in Argo CD with the expected permissions and no sign-in errors appear.
Disable the local admin account
Once at least one SSO user with administrative rights has been verified, set admin.enabled to false in the argocd-cm ConfigMap so the built-in admin user can no longer sign in. The Argo CD user management documentation recommends using the built-in admin user only for initial setup. Keep the break-glass procedure for your cluster documented and tested before you make this change, so that an identity outage does not lock out every operator. The step is done when a sign-in attempt as the local admin is rejected and an SSO administrator can still perform a sync.
How authentik groups map to Argo CD RBAC roles
The groups claim is what turns an authentik group into something Argo CD can authorize. When a user signs in over OIDC, whether directly or through Dex, the token carries that user's group names, and Argo CD matches them against the g lines in the policy.csv key of the argocd-rbac-cm ConfigMap. A line such as g, gitops-payments-devs, role:payments-deployer binds the authentik group gitops-payments-devs to a role. Argo CD reads the claim named under scopes in that ConfigMap, so confirm that your authentik provider sends a groups claim through its scope mapping before writing any rule. Group names are case-sensitive, so copy them from the authentik group list instead of retyping them. Keep policy.default empty so that users without a matching group get no access.
Argo CD defines roles in two places. Global roles live in policy.csv and apply across the whole instance, so reserve them for platform administrators and a read-only viewer. Project roles live under spec.roles in each AppProject, with policies scoped to that project's applications and a groups list that binds authentik groups. Project roles suit GitOps teams because a sync permission granted for team-a/* does not reach another team's applications. The Argo CD upgrade notes for 2.14 to 3.0 changed two behaviors these policies depend on. Update and delete permissions now apply only to the application resource itself, so a rule written to cover managed child objects may grant less than it did. Viewing logs now requires an explicit logs, get permission. Review every existing role for both changes before you upgrade.
Keep the rule set small. For each team, define one read-only role, one sync role scoped to its non-production projects, and a logs role only where engineers need pod logs. Limit production sync to a narrow group, typically platform or release owners, and confirm which teams can sync to production projects during a periodic access review on a cadence your policy requires. Set admin.enabled to false once SSO works, as the user management documentation recommends. If you run Dex, the 3.0 upgrade notes say Dex-based RBAC uses the federated_claims.user_id claim, so check that any user-level bindings match the identifier Dex now emits before you rely on them.
Which authentik attributes and groups map to Argo CD roles
This table compares each authentik attribute or claim with the Argo CD field it feeds, from user subject to RBAC role and project permission. Read it as a checklist: confirm each claim name in the authentik provider and in your Argo CD version before you write policy, because the Dex path and the direct OIDC path do not read claims the same way.
| Authentik source | Argo CD use | What to confirm |
|---|---|---|
| User identifier (subject or username) | Becomes the Argo CD user subject that RBAC rules and audit entries refer to | Choose a stable value such as the username or email, and confirm which claim your provider sends as the subject |
| Email claim | Often used as the readable identity and for matching existing local accounts | Confirm the email claim is present in the ID token and that it is unique and verified in authentik |
| Groups claim | Carries group membership that Argo CD maps to RBAC roles through group names in policy.csv | Confirm the groups scope is requested and the claim name matches the group mapping in your Argo CD config |
| Application scopes (openid, profile, email, groups) | Determine which claims Argo CD receives at login, so a missing scope silently removes groups | Test a login with a non-admin user and inspect the token claims before assigning roles |
| federated_claims.user_id claim (Dex path) | Argo CD 3.0 uses this claim for Dex-based RBAC, so it must reach Argo CD for role matching to work | Confirm the claim name and value against your Argo CD version and your Dex connector output |
| authentik group names | Used as the RBAC subject in role bindings, so names must match exactly, including case | Keep group names stable and document them alongside the Argo CD project and role definitions |
| Admin group membership | Controls which users receive administrative RBAC rights, and should be the smallest set possible | Limit admin rights to a named group and keep the built-in admin account disabled once SSO works |
Hardening the Argo CD and authentik sign-in path
Single sign-on moves the trust decision out of Argo CD and into authentik, so the hardening work has two halves: closing the local login path inside Argo CD and tightening who can reach the application in authentik. The cards below cover both sides, plus the RBAC and session settings that decide what a signed-in GitOps user can change.
Disable the built-in admin user
The built-in admin account is meant for initial setup. Once SSO sign-in has been tested with a named administrator, set admin.enabled to false in the Argo CD configuration so a local password cannot bypass authentik. Keep a tested break-glass path documented before you disable it, and confirm that your SSO administrator group maps to a role that can still manage RBAC. Changes to this setting should go through the same review as other cluster configuration.
Keep the client secret in a Secret
The OIDC client secret issued by authentik should live in a Kubernetes Secret and be referenced from the Argo CD configuration, not written into a ConfigMap or committed to Git. Confirm who can read Secrets in the argocd namespace, since that access effectively grants the ability to impersonate the OIDC client. Plan rotation on authentik's side and the matching Secret update on the Argo CD side as one change, and record who owns each step.
Bind the application to GitOps groups
In authentik, the Argo CD application should be bound only to the groups that need access, with a policy binding that denies everyone else before the token is issued. Without this binding, any authentik user who can reach the application may sign in and receive a role, even if no RBAC rule grants them anything useful. Test with a user outside the groups to confirm the denial happens at authentik, not only inside Argo CD.
Enforce MFA for the application
Argo CD can deploy to production clusters, so the sign-in path should require a second factor for every user who reaches it. Enforce MFA through an authentik flow or policy bound to the Argo CD application, and verify the requirement by signing in with a user who has no enrolled factor. The choice of second factor types and their enrollment is a separate integration topic, so confirm the factors you accept before rollout.
Least-privilege RBAC and projects
Map each authentik group to an Argo CD role with the smallest set of actions it needs, and scope it to Argo CD projects that limit source repositories and destination clusters and namespaces. Since Argo CD 2.14, update and delete RBAC applies only to the application itself, and reading logs requires an explicit logs, get permission, so review each role against those rules. Avoid granting sync rights across all projects to broad groups.
Review token and session settings
Argo CD security documentation covers how sessions, API tokens and related settings behave, and these decide how long a stolen credential stays useful. Review token expiry and session duration against your policy, decide whether automation accounts need API tokens at all, and check how revoking a user in authentik propagates to existing Argo CD sessions. Record the values you chose and the test that confirmed them.
Common Argo CD SSO failures and how to fix them
This table lists the failures teams most often hit when wiring Argo CD to authentik, with the likely cause and the first thing to check for each. Read it by matching the symptom you see at login or in the Argo CD UI to a row, then working through the first fix before changing anything else.
| Symptom | Likely cause | First fix to check |
|---|---|---|
| Redirect error or invalid redirect URI after clicking log in | The redirect URI registered in the authentik OAuth2/OIDC provider does not exactly match the Argo CD external URL (scheme, host, port or path). | Compare the redirect URI in the authentik provider with the Argo CD URL setting, and correct whichever side differs, then retry in a private browser window. |
| User signs in but has no permissions in Argo CD | The groups claim is missing from the ID token, or the authentik group names do not match the subjects in the RBAC policy. | Decode a test token or inspect the claims returned, confirm the groups scope and property mapping are on the provider, then match the group names exactly in policy.csv. |
| Dex connector fails or the login page shows no SSO option | The Dex connector configuration in argocd-cm is malformed, uses the wrong issuer or client secret, or references a secret key that does not exist. | Check the Dex pod logs for the connector error, verify the issuer URL and client credentials, and confirm the referenced secret key name. |
| Users cannot log in after the admin account was disabled | admin.enabled was set to false before any SSO login or local user was verified, so no working login path remained. | Recover through a Kubernetes administrator using the argocd CLI or by editing argocd-cm to re-enable admin temporarily, then fix SSO and disable admin again. |
| Certificate trust error when Argo CD contacts authentik | The authentik endpoint uses a certificate signed by an internal CA that Argo CD or Dex does not trust. | Add the internal CA to the trusted certificates Argo CD uses (or the Dex configuration), then confirm the issuer endpoint is reachable from the Argo CD pods. |
| RBAC change in policy has no effect | Argo CD still uses cached group membership or the user's current session predates the change, or the policy keys do not match the 3.x claim handling. | Ask the user to sign out and sign in again, then confirm the policy references the claim and group values emitted by authentik in the current Argo CD version. |
| Users see applications but cannot view logs or sync | Logs access requires an explicit logs, get permission, and update or delete rights now apply only to the application itself. | Review the policy for a logs, get rule and confirm the role grants the needed actions on the correct project and application. |
| Repository access fails after an upgrade to 3.x | Repository definitions were stored in argocd-cm, which 3.0 no longer reads, so repositories must be Kubernetes Secrets. | Move each repository definition into a labeled Kubernetes Secret, then confirm the controller lists the repositories before testing SSO again. |
Questions teams ask before connecting Argo CD to authentik
Does connecting Argo CD to authentik cost license fees?
Argo CD has no paid edition from the project itself, since it is released under the Apache License 2.0. authentik Open Source is licensed under MIT, and its pricing page lists it as free with community support through Discord. Your costs are therefore labor, infrastructure and any support contract you choose. The main drivers are the number of teams and Argo CD projects, the number of clusters Argo CD manages, and how much group design you need. Ask any partner for a quote built from a written scope that lists the groups, clusters and environments in it.
How long does Argo CD SSO with authentik take to set up?
The duration depends on two things: how mature your existing identity setup is, and how much testing you require before rollout. If authentik already signs users into other applications and your groups are clean, the OIDC configuration itself is a small part of the work. If groups come from a directory that needs cleanup, or if you need to test each RBAC role against real team access, the effort grows. No duration is given here. Ask for a timeline that separates identity preparation, Argo CD configuration, role testing and rollout, and ask which of those steps the quote covers.
What does the platform team need to provide for this work?
The platform team needs to supply access and decisions that only your organization can make. That includes administrative access to the authentik instance and to the Argo CD namespace, a list of Argo CD projects and the clusters they target, the groups that should map to each role, and a test user for each team. The team also needs to decide whether Argo CD uses authentik directly over OIDC or through the bundled Dex, and who approves changes to the RBAC policy. Plan for a named reviewer on both the identity and the Kubernetes side.
Can our own team set up Argo CD SSO with authentik without a partner?
Yes, if your team already operates both authentik and Argo CD and has someone who can work in both. The configuration is documented by each project, and the hardest parts are usually group design and verification rather than the initial settings. Teams that run Argo CD for many projects often find the RBAC mapping takes longer than expected because roles must match real responsibilities. A partner is most useful when the group model is unclear, when several clusters need consistent access, or when you want an independent review before production use.
Do we need authentik Enterprise for Argo CD SSO?
Based on the pricing page, the Enterprise features listed are Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support. None of these is named as a requirement for an OIDC connection from Argo CD to authentik. Whether you need them depends on your own policy, for example if you want audit logging of sign-in events or if your directory is Entra ID. Confirm the exact feature set against the current pricing page and your own requirements before you decide.
How do authentik groups map to Argo CD RBAC roles?
Argo CD reads group claims from the identity token and maps them to roles through its RBAC policy, so each authentik group that should have access needs a matching role binding. Groups should be designed around responsibilities, such as read-only access for auditors, sync rights for application teams and admin rights for platform staff. Keep the number of groups small and align them with Argo CD projects so that each team only sees its own applications. Test each mapping with a user from every group before rollout, and confirm the claim name in your version of Argo CD.
What breaks most often in Argo CD SSO with authentik?
The most common problems are a redirect URL or issuer that does not match exactly, a group claim that is missing from the token, and an RBAC policy that grants more access than intended. Teams also lose access when they disable the local admin user before SSO is confirmed working. The Argo CD user management documentation recommends using the built-in admin account only for initial setup and disabling it with admin.enabled set to false once SSO works. Keep the admin account available until every role has been tested with a real login.
What should we ask for in a quote for this integration?
Ask for a written scope that lists the authentik and Argo CD versions in use, whether OIDC is direct or through Dex, the groups and roles to be mapped, the number of clusters and Argo CD projects in scope, and the test cases each role must pass. Ask which items are one-time work, such as the initial configuration, and which recur, such as updates after each Argo CD minor release. Ask how the quote handles the documentation and handover of the RBAC policy, and whether any environment preparation is excluded.
How DeployOpen scopes and delivers the Argo CD SSO integration
DeployOpen plans the authentik and Argo CD SSO integration as a written, fixed-scope engagement inside your own clusters and identity environment. The work covers the OIDC client setup, the choice between direct OIDC and Dex, group-to-role mapping, testing and handover documentation for your GitOps team.
How we scope
- We confirm which Argo CD version and deployment model your clusters run before any configuration starts.
- We agree in writing whether authentik connects directly over OIDC or through the bundled Dex.
- We define which authentik groups map to which Argo CD roles, and which teams keep local admin access.
How we build
- We create the authentik OAuth2/OIDC provider and application, with redirect URIs matched to your Argo CD hostname.
- We configure the Argo CD OIDC settings and RBAC policy in your GitOps repository under change control.
- We test login, group claims and denied access for each role using accounts your team supplies.
How we hand over
- We document the provider settings, claim names, RBAC mappings and the steps to disable the built-in admin user.
- We walk your platform and identity owners through the configuration and the test results before close.
- We record open decisions, such as group ownership and offboarding steps, so your team can run them after handover.
How we support
- Engagements are fixed-scope, so changes after sign-off go through a written change to the scope.
- Ongoing support, upgrades and continuous testing are available as a retainer, including reviews after Argo CD minor releases.
- Your team keeps ownership of the authentik and Argo CD environments, with DeployOpen documenting each change it makes.
