Access control and user management
Configuring user authentication and access controls for users and namespaces
Abstract
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.
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
Edit the
argocdCR:$ oc edit argocd [argocd-instance-name] -n [namespace]
Output
metadata ... ... rbac: policy: 'g, rbacsystem:cluster-admins, role:admin' scopes: '[groups]'Add the
policyconfiguration to therbacsection and add thenameand the desiredroleto be applied to the user:metadata ... ... 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
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).
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.
2.1. Configuration to enable the Dex OpenShift OAuth Connector
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.providerparameter todexin the YAML resource of the Operator:# ... spec: sso: provider: dex dex: openShiftOAuth: true 1 # ...- 1
- The
openShiftOAuthproperty triggers the Operator to automatically configure the built-in OpenShift Container PlatformOAuthserver when the value is set totrue.
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
Create a group named
cluster-admins.$ oc adm groups new cluster-admins
Add the user to the group.
$ oc adm groups add-users cluster-admins USER
Apply the
cluster-adminClusterRoleto 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.ssoelement from the Argo CD custom resource or specify a different SSO provider.
Chapter 3. 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.
3.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
3.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.
| 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: false3.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.
Table 3.1. Summary of local user configuration
| 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 with API key enabled and a non-expiring token.
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
name: example-argocd
spec:
localUsers:
- name: developerThe 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: trueThe 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: falseThe 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 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: trueThe 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: true3.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-settingThe 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
3.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
apikeyfield tofalse.
3.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
enabledfield tofalse. 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
localUserslist 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.
3.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
# ...
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.
3.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-gitopsnamespace.
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
specsection of the Argo CD CR, add alocalUsersconfiguration. 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: falseSave and close the file.
The Operator reconciles the changes and creates the required secrets and API tokens automatically.