Access control and user management


Red Hat OpenShift GitOps 1.20

Configuring user authentication and access controls for users and namespaces

Red Hat OpenShift Documentation Team

Abstract

This document provides instructions for changing and managing user level access and resource requests. It also discusses how to configure role-based access control and single sign-on authentication providers to manage multiple users, permissions, Argo CD resources, and instances in the cluster.

Chapter 1. Configuring Argo CD RBAC

By default, any type of user, except the

kube:admin
user, logged into the default Argo CD instance does not have access to any services. But a user logged into a custom Argo CD instance is a read-only user by default.

Note

In Red Hat OpenShift GitOps v1.9.0 or earlier versions, any type of user, except the

kube:admin
user, logged into Argo CD using Red Hat SSO (RH SSO) is a read-only user by default.

1.1. Configuring user level access

To manage and modify the user level access, configure the role-based access control (RBAC) section in the Argo CD custom resource (CR).

Procedure

  1. Edit the

    argocd
    CR:

    $ oc edit argocd [argocd-instance-name] -n [namespace]

    Output:

    metadata
    ...
    ...
      rbac:
        policy: 'g, rbacsystem:cluster-admins, role:admin'
        scopes: '[groups]'
  2. Add the

    policy
    configuration to the
    rbac
    section and add the
    name
    and the desired
    role
    to be applied to the user:

    metadata
    ...
    ...
    rbac:
        policy: g, <name>, role:<admin>
        scopes: '[groups]'
Note

Currently, RHSSO cannot read the group information of Red Hat OpenShift GitOps users. Therefore, configure the RBAC at the user level.

Chapter 2. Configuring SSO for Argo CD using Dex

After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with

admin
permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO).

Note

The

spec.dex
parameter in the ArgoCD CR is no longer supported from Red Hat OpenShift GitOps v1.10.0 onwards. Consider using the
.spec.sso
parameter instead.

Dex is installed by default for all the Argo CD instances created by the Operator. You can configure Red Hat OpenShift GitOps to use Dex as the SSO authentication provider by setting the

.spec.sso
parameter.

Dex uses the users and groups defined within OpenShift Container Platform by checking the

OAuth
server provided by the platform.

Procedure

  • To enable Dex, set the

    .spec.sso.provider
    parameter to
    dex
    in the YAML resource of the Operator:

    # ...
    spec:
      sso:
        provider: dex
        dex:
          openShiftOAuth: true
    # ...

    where:

    spec.sso.dex.openShiftOAuth
    Specifies the openShiftOAuth property that triggers the Operator to automatically configure the built-in OpenShift Container Platform OAuth server when the value is set to true.
Important
  • When external authentication is enabled at the cluster level, the
    spec.sso
    configuration (including
    spec.sso.provider: dex
    and
    spec.sso.keycloak
    ) might not function as expected for the Argo CD instance.
  • In such cases, you must configure OIDC directly using
    spec.oidcConfig
    and either set
    spec.sso
    to
    null
    or remove it from the Argo CD custom resource.
  • You cannot use
    spec.sso
    and
    spec.oidcConfig
    simultaneously. Including both configurations in the Argo CD instance will result in a validation error.

2.1.1. Mapping users to specific roles

Argo CD cannot map users to specific roles if they have a direct

ClusterRoleBinding
role. You can manually change the role as
role:admin
on SSO through OpenShift.

Procedure

  1. Create a group named

    cluster-admins
    .

    $ oc adm groups new cluster-admins
  2. Add the user to the group.

    $ oc adm groups add-users cluster-admins USER
  3. Apply the

    cluster-admin
    ClusterRole
    to the group:

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admins

2.2. Disabling Dex by replacing .spec.sso

  • To disable dex, either remove the
    spec.sso
    element from the Argo CD custom resource or specify a different SSO provider.

After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with

admin
permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO) with external OpenID Connect (OIDC) providers.

Argo CD supports Single Sign-On (SSO) using OpenID Connect (OIDC) providers. You can integrate Argo CD with identity providers using the following two primary approaches:

Dex-based SSO (spec.sso)
Argo CD uses Dex as an intermediary identity broker. Dex connects to various identity providers and presents a unified authentication interface to Argo CD.
Direct OIDC integration (spec.oidcConfig)
Argo CD connects directly to an external OIDC-compliant provider without using Dex as an intermediary.

Direct OIDC integration (

spec.oidcConfig
) is provider-agnostic and works with any OIDC-compliant identity provider.

This approach requires that you configure the identity provider according to its official documentation before updating the Argo CD instance configuration. For more information, see the Additional resources section.

3.2. Prerequisites

  • The Red Hat OpenShift GitOps Operator is installed on your OpenShift Container Platform cluster.
  • You have access to the cluster with
    cluster-admin
    privileges.
  • You have configured an OIDC-compliant identity provider according to the provider’s official documentation.
  • You have obtained the following information from your OIDC provider:

    • Issuer URL
    • Client ID
    • Client secret

You can configure Argo CD to authenticate users directly with an external OIDC provider by using the

spec.oidcConfig
parameter in the Argo CD custom resource. This method bypasses Dex and connects Argo CD directly to your identity provider.

Procedure

  1. Edit the ArgoCD custom resource for your instance:

    $ oc edit argocd <argocd_instance_name> -n <argocd_instance_namespace>

    Replace

    <argocd_instance_name>
    with the name of your Argo CD instance, for example,
    openshift-gitops
    , and
    <argocd_instance_namespace>
    with the namespace where the instance is deployed, for example,
    openshift-gitops
    .

  2. Add or update the

    spec.oidcConfig
    parameter with your OIDC provider details:

    apiVersion: argoproj.io/v1beta1
    kind: ArgoCD
    metadata:
      name: <argocd_instance_name>
      namespace: <argocd_instance_namespace>
    spec:
      oidcConfig: |
        name: <provider_name>
        issuer: https://<issuer-url>
        clientID: <client_id>
        clientSecret: <client_secret>
        requestedScopes:
          - openid
          - profile
          - email
          - groups
        requestedIDTokenClaims:
          groups:
            essential: true
        logoutURL: https://<optional-logout-url>

    where:

    metadata.name
    Specifies the name of your Argo CD instance.
    metadata.namespace
    Specifies the namespace where your Argo CD instance is deployed.
    spec.oidcConfig.issuer
    Specifies the OIDC issuer URL provided by your identity provider.
    spec.oidcConfig.clientid
    Specifies the client ID obtained from your OIDC provider.
    spec.oidcConfig.clientSecret
    Specifies the client secret obtained from your OIDC provider.
    spec.oidcConfig.requestedScopes
    Specifies the OIDC scopes to request during authentication. Common scopes include openid, profile, email, and groups. Adjust based on your provider’s supported scopes.
    spec.oidcConfig.requestedIDTokenClaims
    Specifies the claims to request in the ID token. This parameter is optional.
    spec.oidcConfig.logoutURL
    Specifies the logout URL provided by your identity provider. This parameter is optional.
    <provider_name>
    Specifies a a unique identifier for the OIDC provider configuration.
  3. Save the changes into a YAML file, for example,
    argocd-oidc.yaml
    .
  4. Apply the configuration by running the following command.

    $ oc apply -f argocd-oidc.yaml
  5. Restart the Argo CD server to apply the OIDC configuration:

    $ oc rollout restart deployment/<argocd_instance_name>-server -n <argocd_instance_namespace>
  6. Run the following command to verify that the rollout completed successfully:

    $ oc rollout status deployment/<argocd_instance_name>-server -n <argocd_instance_namespace>

    Example output:

    deployment "openshift-gitops-server" successfully rolled out

3.4. Verifying OIDC login for Argo CD

After configuring direct OIDC integration, you can verify that the authentication is working correctly by accessing the Argo CD web UI and logging in with your identity provider credentials.

Procedure

  1. Open the Argo CD route URL in a web browser.
  2. On the Argo CD login page, verify that a login option appears with the name you configured in the
    spec.oidcConfig.name
    parameter. For example,
    LOG IN VIA <provider_name>
    .
  3. Authenticate using your identity provider credentials.
  4. After successful authentication, verify the access and role-based permissions.

Chapter 4. Managing local users in Argo CD

The Argo CD Operator provides built-in support for managing local users with automatic API token generation and renewal. As an administrator, you can declaratively define local users in the Argo CD custom resource (CR), and the Red Hat OpenShift GitOps Operator manages their API tokens throughout their lifecycle.

4.1. About local user management in Argo CD

Local users are intended for automation scenarios that require API tokens or for small teams where configuring single sign-on (SSO) is not necessary.

The Argo CD Operator manages local users by performing the following actions:

  • Creating and managing user accounts defined in the Argo CD CR
  • Generating JSON Web Token (JWT) API tokens
  • Configuring token lifetimes and automatic renewal
  • Storing tokens securely in Kubernetes secrets
  • Cleaning up users and tokens when they are removed from the configuration

4.2. Local user configuration in Argo CD

Local users are defined in the

.spec.localUsers
field of the Argo CD custom resource (CR). Each user definition includes required and optional configuration fields.

The following table describes configuration fields for local users.

Expand
FieldTypeDefault valueDescriptionOptional

name

String

None

Unique username for the local user.

No

enabled

Boolean

true

Enables or disables the user. Disabled users cannot login or use an API token to access the Argo CD instance, but their configuration and tokens are preserved.

Yes

apiKey

Boolean

true

Enables API token generation for the user.

Yes

login

Boolean

false

Enables login through the Argo CD web UI. If enabled, you must set a password manually by using the Argo CD CLI.

Yes

tokenLifetime

String

0h

Duration that the token remains valid, for example

24h
or
168h
. Uses the Go duration format. The default
0h
value creates a non-expiring token.

Yes

autoRenewToken

Boolean

true

Enables automatic renewal before expiration. Applies only when

tokenLifetime
is greater than
0h
.

Yes

The following configuration creates two local users in an Argo CD CR, each with different API key settings.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
  namespace: argocd
spec:
  localUsers:
    - name: api-user
      apiKey: true
      tokenLifetime: "24h"
      autoRenewToken: true
    - name: service-account
      apiKey: true
      tokenLifetime: "168h"
      autoRenewToken: false

4.3. Example local user configuration in Argo CD

You can configure local users for Argo CD in different ways depending on whether you need long-lived API tokens, renewable tokens, or accounts with UI login capability. The following examples display common configuration patterns for local users.

Expand
Table 4.1. Summary of local user configuration
User typeLogin enabledAPI keyToken lifetimeAuto-renew

Basic local user

No

Yes

Non-expiring

No

Expiring token user

No

Yes

30 days

Yes

Long-lived token user

No

Yes

1 year

No

User with login capability

Yes

Yes

24 hours

Yes

Disabled user

No

Yes

Retains configuration

No

API-only user

No

Yes

7 days

Yes

The following configuration creates a local user named

developer
with API key enabled and a non-expiring token.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  localUsers:
    - name: developer

The following configuration creates a user with a 30-day token lifetime and automatic renewal.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  localUsers:
    - name: ci-system
      apiKey: true
      tokenLifetime: "720h"
      autoRenewToken: true

The following configuration creates a user with a one-year token lifetime without automatic renewal.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  localUsers:
    - name: monitoring
      apiKey: true
      tokenLifetime: "8760h"  # 1 year
      autoRenewToken: false

The following configuration creates a user who can log in to the Argo CD web UI and also use an API token.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  localUsers:
    - name: developer
      enabled: true
      login: true
      apiKey: true
      tokenLifetime: "24h"
      autoRenewToken: true
Important

When

login: true
is enabled, you must set a password manually by using the Argo CD CLI. You cannot log in to the Argo CD web UI without a password.

The following configuration defines a user account that is disabled but retains its configuration and token data.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  localUsers:
    - name: temp-user
      enabled: false
      apiKey: true

The following configuration creates a user for programmatic access with API key enabled, UI login disabled, and a renewable 7-day token.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  localUsers:
    - name: automation
      enabled: true
      login: false
      apiKey: true
      tokenLifetime: "168h"
      autoRenewToken: true

4.4. Token storage and access

For each local user, the Argo CD Operator creates a Kubernetes secret in the same namespace as the Argo CD instance. The secret name follows the format

{username}-local-user
.

The following example shows the Kubernetes

Secret
that stores a local user’s API token and configuration details.

apiVersion: v1
kind: Secret
metadata:
  name: api-user-local-user
  namespace: argocd
  labels:
    app.kubernetes.io/component: local-users
    app.kubernetes.io/managed-by: argocd-operator
type: Opaque
data:
  apiToken: base64-encoded-jwt-token
  user: base64-encoded-username
  expAt: base64-encoded-expiration-timestamp
  tokenLifetime: base64-encoded-lifetime-setting
  autoRenew: base64-encoded-auto-renew-setting
Important

The values in the secret are base64-encoded. You must decode them before using.

Retrieve tokens

You can retrieve a user’s API token from the Kubernetes secret, as shown in the following example:

$ oc get secret api-user-local-user -n argocd -o jsonpath='{.data.apiToken}' | base64 -d
Use tokens

You can use the retrieved token with the Argo CD CLI to list applications, as shown in the following example. The token can also be used with other Argo CD CLI commands in a similar way.

$ argocd --server <argocd-server> --auth-token <token> app list

4.5. Token lifecycle management

The Argo CD Operator manages the lifecycle of local user tokens. Depending on the configuration, tokens can be renewed automatically or rotated manually.

Automatic renewal
You can configure the Operator to automatically renew tokens before they expire. This ensures that automation and integrations that depend on the token continue to work without interruption.
Manual token rotation

If you need to replace a token immediately, you can manually rotate it by deleting the user secret, as shown in the following example:

---
$ oc delete secret api-user-local-user -n argocd
---

The Argo CD Operator then generates a new token and updates the configuration.

Disable API keys
You can disable API key generation for a local user to remove their access through tokens. Disabling API keys also cleans up the associated secrets and stops renewal timers. To disable API key generation, you can set apikey field to false.

4.6. User lifecycle management

The Argo CD Operator also manages the lifecycle of local user accounts. You can temporarily disable users without removing them from the configuration, or permanently remove them when they are no longer required.

Disable users

You can disable a user by setting the

enabled
field to
false
. When a user is disabled, the following behaviors apply:

  • The user account remains in the Argo CD configuration, but it is set to disabled.
  • The user secret and tokens are preserved.
  • The user cannot authenticate by using the UI or by the API tokens.
  • Token renewal timers continue to run, if configured.
  • Re-enabling the user (
    enabled: true
    ) immediately restores access.
User removal

You can remove a user completely by deleting the entry from the

localUsers
list in the Argo CD CR. When a user is removed, the following behaviors apply:

  • The user secret is deleted.
  • The token is removed from the Argo CD configuration.
  • Any scheduled token renewal timers are canceled.
  • The user account is removed from Argo CD.

4.7. Integration with legacy configuration

The Argo CD Operator recognizes users defined in the

extraConfig
section of the Argo CD custom resource (CR). Tokens defined for these users are not managed by the Operator. This behavior allows you to gradually migrate from manually-managed users to Operator-managed users.

# ...
spec:
  extraConfig:
    accounts.legacy-user: apiKey
  localUsers:
    - name: new-user
      apiKey: true
# ...
Important

A user must be defined in only one section, either

extraConfig
or
localUsers
. If a user appears in both sections, the definition in
extraConfig
takes precedence and the definition in
localUsers
is ignored.

4.8. Creating local users in Argo CD

You can configure local users with API keys for access to Argo CD. The Argo CD Operator manages these users and securely generates API tokens for service accounts or automation scripts.

Prerequisites

  • You are logged in to the OpenShift Container Platform cluster as an administrator.
  • You installed the Red Hat OpenShift GitOps Operator on your OpenShift Container Platform cluster.
  • You can access the default Argo CD instance in the
    openshift-gitops
    namespace.

Procedure

  1. Edit the Argo CD custom resource (CR) for your instance by running the following command:

    $ oc edit argocd <argocd-instance-name> -n <namespace>
  2. In the

    spec
    section of the Argo CD CR, add a
    localUsers
    configuration. For example:

    spec:
      localUsers:
      - name: "alice"
        enabled: true
        apiKey: true
        login: false
        tokenLifetime: "24h"
        autoRenewToken: true
      - name: "service-account"
        enabled: true
        apiKey: true
        login: false
        tokenLifetime: "0h"  # Infinite lifetime
        autoRenewToken: false
  3. Save and close the file.

    The Operator reconciles the changes and creates the required secrets and API tokens automatically.

Legal Notice

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top