Access control and user management


Red Hat OpenShift GitOps 1.16

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.

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.provider parameter to dex in the YAML resource of the Operator:

    # ...
    spec:
      sso:
        provider: dex
        dex:
          openShiftOAuth: true 1
    # ...
    1
    The openShiftOAuth property triggers the Operator to automatically configure the built-in OpenShift Container Platform OAuth server when the value is set to true.

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.

Chapter 3. Configuring SSO for Argo CD using Keycloak

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).

3.1. Prerequisites

  • Red Hat SSO is installed on the cluster.
  • The Red Hat OpenShift GitOps Operator is installed on your OpenShift Container Platform cluster.
  • Argo CD is installed on the cluster.
  • The DeploymentConfig API is available in the cluster. For more information, see "DeploymentConfig [apps.openshift.io/v1]".
  • When the Red Hat OpenShift GitOps Operator is deployed on an OpenShift Container Platform cluster configured for FIPS mode, Single Sign-on (SSO) configuration for Argo CD using Keycloak is not supported.

3.2. Configuring a new client in Keycloak

Dex is installed by default for all the Argo CD instances created by the Operator. However, you can delete the Dex configuration and add Keycloak instead to log in to Argo CD using your OpenShift credentials. Keycloak acts as an identity broker between Argo CD and OpenShift.

Procedure

To configure Keycloak, follow these steps:

  1. Delete the Dex configuration by removing the .spec.sso.dex parameter from the Argo CD custom resource (CR), and save the CR:

    dex:
        openShiftOAuth: true
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
  2. Set the value of the provider parameter to keycloak in the Argo CD CR.
  3. Configure Keycloak by performing one of the following steps:

    • For a secure connection, set the value of the rootCA parameter as shown in the following example:

      apiVersion: argoproj.io/v1beta1
      kind: ArgoCD
      metadata:
        name: example-argocd
        labels:
          example: basic
      spec:
        sso:
          provider: keycloak
          keycloak:
            rootCA: "<PEM-encoded-root-certificate>" 1
        server:
          route:
            enabled: true
      1
      A custom certificate used to verify the Keycloak’s TLS certificate.

      The Operator reconciles changes in the .spec.sso.keycloak.rootCA parameter and updates the oidc.config parameter with the PEM encoded root certificate in the argocd-cm configuration map.

    • For an insecure connection, leave the value of the rootCA parameter empty and use the oidc.tls.insecure.skip.verify parameter as shown below:

      apiVersion: argoproj.io/v1beta1
      kind: ArgoCD
      metadata:
        name: example-argocd
        labels:
          example: basic
      spec:
        extraConfig:
          oidc.tls.insecure.skip.verify: "true"
        sso:
          provider: keycloak
          keycloak:
            rootCA: ""
    • Optional: Customize the spec.sso.keycloak field to add the route name for the keycloak provider in the ArgoCD CR. Use this feature to support advanced routing use cases, such as balancing incoming traffic load among multiple Ingress Controller sharding.

      • Add a host parameter in the ArgoCD CR by using the following example YAML:

        Example ArgoCD CR

        apiVersion: argoproj.io/v1alpha1
        kind: ArgoCD
        metadata:
          name: <resource_name> 1
          labels:
            example: route
        spec:
          sso:
            provider: keycloak
            keycloak:
             host: <hostname> 2
          server:
            ingress:
              enabled: true
            insecure: true

        1
        Replace <resource_name> with the name of the ArgoCD CR.
        2
        Replace <hostname> with the name of the host key, for example, sso.test.example.com.
      • To create the ArgoCD CR, run the following command:

        $ oc create -f <argocd_filename>.yaml -n <your-namespace>
      • To edit the ArgoCD CR, run the following command:

        $ oc edit -f <argocd_filename>.yaml -n <your_namespace>
      • Save the file to apply the changes.
      • To apply the ArgoCD CR, run the following command:

        $ oc apply -f <argocd_filename>.yaml -n <your_namespace>
      • Verify that the host attribute is added by running the following command:

        $ oc get route keycloak -n <your_namespace> -o yaml

        Example output

        kind: Route
        metadata:
          name: keycloak 1
          labels:
            application: keycloak
        spec:
          host: sso.test.example.com
        status:
          ingress:
            - host: sso.test.example.com 2

        1
        Specifies the name of the route.
        2
        Specifies the name of the host key.
        Note

        The Keycloak instance takes 2-3 minutes to install and run.

3.3. Logging in to Keycloak

Log in to the Keycloak console to manage identities or roles and define the permissions assigned to the various roles.

Prerequisites

  • The default configuration of Dex is removed.
  • Your Argo CD CR must be configured to use the Keycloak SSO provider.

Procedure

  1. Get the Keycloak route URL for login:

    $ oc -n argocd get route keycloak
    
    NAME        HOST/PORT                                                        PATH   SERVICES   PORT    TERMINATION   WILDCARD
    keycloak    keycloak-default.apps.ci-ln-******.origin-ci-int-aws.dev.**.com         keycloak   <all>    reencrypt     None
  2. Get the Keycloak pod name that stores the user name and password as environment variables:

    $ oc -n argocd get pods
    
    NAME                      READY   STATUS           RESTARTS   AGE
    keycloak-1-2sjcl           1/1    Running            0        45m
    1. Get the Keycloak user name:

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME
      
      SSO_ADMIN_USERNAME=Cqid54Ih
    2. Get the Keycloak password:

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD
      
      SSO_ADMIN_PASSWORD=GVXxHifH
  3. On the login page, click LOG IN VIA KEYCLOAK.

    Note

    You only see the option LOGIN VIA KEYCLOAK after the Keycloak instance is ready.

  4. Click Login with OpenShift.

    Note

    Login using kubeadmin is not supported.

  5. Enter the OpenShift credentials to log in.
  6. Optional: By default, any user logged in to Argo CD has read-only access. You can manage the user level access by updating the argocd-rbac-cm config map:

    policy.csv:
    <name>, <email>, role:admin

3.4. Uninstalling Keycloak

You can delete the Keycloak resources and their relevant configurations by removing the SSO field from the Argo CD Custom Resource (CR) file. After you remove the SSO field, the values in the file look similar to the following:

  apiVersion: argoproj.io/v1beta1
  kind: ArgoCD
  metadata:
    name: example-argocd
    labels:
      example: basic
  spec:
    server:
      route:
       enabled: true
Note

A Keycloak application created by using this method is currently not persistent. Additional configurations created in the Argo CD Keycloak realm are deleted when the server restarts.

3.5. Modifying Keycloak resource requests/limits

By default, the Keycloak container is created with resource requests and limitations. You can change and manage the resource requests.

ResourceRequestsLimits

CPU

500m

1000m

Memory

512 Mi

1024 Mi

Procedure

  • Modify the default resource requirements patching the Argo CD custom resource (CR):
$ oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]'
Note

Keycloak created by the Red Hat OpenShift GitOps Operator only persists the changes that are made by the Operator. If the Keycloak restarts, any additional configuration created by the administrator in Keycloak is deleted.

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, 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, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
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.

© 2024 Red Hat, Inc.