Access control and user management
Configuring user authentication and access controls for users and namespaces
Abstract
Chapter 1. Configuring Argo CD RBAC Copy linkLink copied to clipboard!
By default, any type of user, except the
kube:admin
In Red Hat OpenShift GitOps v1.9.0 or earlier versions, any type of user, except the
kube:admin
1.1. Configuring user level access Copy linkLink copied to clipboard!
To manage and modify the user level access, configure the role-based access control (RBAC) section in the Argo CD custom resource (CR).
Procedure
Edit the
CR:argocd$ oc edit argocd [argocd-instance-name] -n [namespace]Output:
metadata ... ... rbac: policy: 'g, rbacsystem:cluster-admins, role:admin' scopes: '[groups]'Add the
configuration to thepolicysection and add therbacand the desirednameto be applied to the user:rolemetadata ... ... rbac: policy: g, <name>, role:<admin> scopes: '[groups]'
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 Copy linkLink copied to clipboard!
After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with
admin
The
spec.dex
.spec.sso
2.1. Configuration to enable the Dex OpenShift OAuth Connector Copy linkLink copied to clipboard!
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
Dex uses the users and groups defined within OpenShift Container Platform by checking the
OAuth
Procedure
To enable Dex, set the
parameter to.spec.sso.providerin the YAML resource of the Operator:dex# ... spec: sso: provider: dex dex: openShiftOAuth: true # ...where:
spec.sso.dex.openShiftOAuth-
Specifies the
openShiftOAuthproperty that triggers the Operator to automatically configure the built-in OpenShift Container PlatformOAuthserver when the value is set totrue.
-
When external authentication is enabled at the cluster level, the configuration (including
spec.ssoandspec.sso.provider: dex) might not function as expected for the Argo CD instance.spec.sso.keycloak -
In such cases, you must configure OIDC directly using and either set
spec.oidcConfigtospec.ssoor remove it from the Argo CD custom resource.null -
You cannot use and
spec.ssosimultaneously. Including both configurations in the Argo CD instance will result in a validation error.spec.oidcConfig
2.1.1. Mapping users to specific roles Copy linkLink copied to clipboard!
Argo CD cannot map users to specific roles if they have a direct
ClusterRoleBinding
role:admin
Procedure
Create a group named
.cluster-admins$ oc adm groups new cluster-adminsAdd the user to the group.
$ oc adm groups add-users cluster-admins USERApply the
cluster-adminto the group:ClusterRole$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
2.2. Disabling Dex by replacing .spec.sso Copy linkLink copied to clipboard!
-
To disable dex, either remove the element from the Argo CD custom resource or specify a different SSO provider.
spec.sso
Chapter 3. Configuring SSO for Argo CD using external OIDC providers Copy linkLink copied to clipboard!
After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with
admin
3.1. Understanding OIDC integration approaches for Argo CD Copy linkLink copied to clipboard!
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
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 Copy linkLink copied to clipboard!
- The Red Hat OpenShift GitOps Operator is installed on your OpenShift Container Platform cluster.
-
You have access to the cluster with privileges.
cluster-admin - 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
3.3. Configuring direct OIDC integration for Argo CD Copy linkLink copied to clipboard!
You can configure Argo CD to authenticate users directly with an external OIDC provider by using the
spec.oidcConfig
Procedure
Edit the ArgoCD custom resource for your instance:
$ oc edit argocd <argocd_instance_name> -n <argocd_instance_namespace>Replace
with the name of your Argo CD instance, for example,<argocd_instance_name>, andopenshift-gitopswith the namespace where the instance is deployed, for example,<argocd_instance_namespace>.openshift-gitopsAdd or update the
parameter with your OIDC provider details:spec.oidcConfigapiVersion: 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, andgroups. 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.
-
Save the changes into a YAML file, for example, .
argocd-oidc.yaml Apply the configuration by running the following command.
$ oc apply -f argocd-oidc.yamlRestart the Argo CD server to apply the OIDC configuration:
$ oc rollout restart deployment/<argocd_instance_name>-server -n <argocd_instance_namespace>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 Copy linkLink copied to clipboard!
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
- Open the Argo CD route URL in a web browser.
-
On the Argo CD login page, verify that a login option appears with the name you configured in the parameter. For example,
spec.oidcConfig.name.LOG IN VIA <provider_name> - Authenticate using your identity provider credentials.
- After successful authentication, verify the access and role-based permissions.
Chapter 4. Managing local users in Argo CD Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
Local users are defined in the
.spec.localUsers
The following table describes configuration fields for local users.
| Field | Type | Default value | Description | Optional |
|---|---|---|---|---|
|
| String | None | Unique username for the local user. | No |
|
| Boolean |
| 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 |
|
| Boolean |
| Enables API token generation for the user. | Yes |
|
| Boolean |
| Enables login through the Argo CD web UI. If enabled, you must set a password manually by using the Argo CD CLI. | Yes |
|
| String |
| Duration that the token remains valid, for example
| Yes |
|
| Boolean |
| Enables automatic renewal before expiration. Applies only when
| 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 Copy linkLink copied to clipboard!
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.
| User type | Login enabled | API key | Token lifetime | Auto-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
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
When
login: true
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 Copy linkLink copied to clipboard!
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
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
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 Copy linkLink copied to clipboard!
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
apikeyfield tofalse.
4.6. User lifecycle management Copy linkLink copied to clipboard!
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
field toenabled. When a user is disabled, the following behaviors apply:false- 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 () immediately restores access.
enabled: true
- User removal
You can remove a user completely by deleting the entry from the
list in the Argo CD CR. When a user is removed, the following behaviors apply:localUsers- 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 Copy linkLink copied to clipboard!
The Argo CD Operator recognizes users defined in the
extraConfig
# ...
spec:
extraConfig:
accounts.legacy-user: apiKey
localUsers:
- name: new-user
apiKey: true
# ...
A user must be defined in only one section, either
extraConfig
localUsers
extraConfig
localUsers
4.8. Creating local users in Argo CD Copy linkLink copied to clipboard!
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 namespace.
openshift-gitops
Procedure
Edit the Argo CD custom resource (CR) for your instance by running the following command:
$ oc edit argocd <argocd-instance-name> -n <namespace>In the
section of the Argo CD CR, add aspecconfiguration. For example:localUsersspec: 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: falseSave and close the file.
The Operator reconciles the changes and creates the required secrets and API tokens automatically.