Declarative cluster configuration

Procedure

1. In the Administrator perspective of the web console, navigate to Operators → Installed Operators → Red Hat OpenShift GitOps → Subscription.
2. Click the Actions list and then click Edit Subscription.

3. On the openshift-gitops-operator Subscription details page, under the YAML tab, edit the Subscription YAML file by adding the namespace of the Argo CD instance to the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable in the spec section:

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-gitops-operator
     namespace: openshift-gitops-operator
   # ...
   spec:
     config:
       env:
       - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES
         value: openshift-gitops, <list of namespaces of cluster-scoped Argo CD instances>
   # ...

4. Click Save and Reload.

5. To verify that the Argo CD instance is configured with a cluster role to manage cluster-scoped resources, perform the following steps:

   1. Navigate to User Management → Roles and from the Filter list select Cluster-wide Roles.

   2. Search for the argocd-application-controller by using the Search by name field.

      The Roles page displays the created cluster role.

      Tip

      Alternatively, in the OpenShift CLI, run the following command:

      oc auth can-i create oauth -n openshift-gitops --as system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller

      The output yes verifies that the Argo instance is configured with a cluster role to manage cluster-scoped resources. Else, check your configurations and take necessary steps as required.

Procedure

1. Label the existing nodes:

   $ oc label node <node-name> node-role.kubernetes.io/infra=""

2. Optional: If required, you can also apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes:

   $ oc adm taint nodes -l node-role.kubernetes.io/infra \
   infra=reserved:NoSchedule infra=reserved:NoExecute

3. Add the runOnInfra toggle in the GitOpsService custom resource:

   apiVersion: pipelines.openshift.io/v1alpha1
   kind: GitopsService
   metadata:
     name: cluster
   spec:
     runOnInfra: true

4. Optional: If taints have been added to the nodes, then add tolerations to the GitOpsService custom resource.

   Example

   apiVersion: pipelines.openshift.io/v1alpha1
   kind: GitopsService
   metadata:
     name: cluster
     spec:
       runOnInfra: true
       tolerations:
       - effect: NoSchedule
         key: infra
         value: reserved
       - effect: NoExecute
         key: infra
         value: reserved

5. Verify that the workloads in the openshift-gitops namespace are now scheduled on the infrastructure nodes by viewing Pods → Pod details for any pod in the console UI.

Procedure

1. In the Argo CD dashboard, click NEW APP to add a new Argo CD application.

2. For this workflow, create a cluster-configs application with the following configurations:

   Application Name

   cluster-configs

   Project

   default

   Sync Policy

   Manual

   Repository URL

   https://github.com/redhat-developer/openshift-gitops-getting-started

   Revision

   HEAD

   Path

   cluster

   Destination

   https://kubernetes.default.svc

   Namespace

   spring-petclinic

   Directory Recurse

   checked

3. Click CREATE to create your application.
4. Open the Administrator perspective of the web console and expand Administration → Namespaces.
5. Search for and select the namespace, then enter argocd.argoproj.io/managed-by=openshift-gitops in the Label field so that the Argo CD instance in the openshift-gitops namespace can manage your namespace.

Procedure

1. Download the sample application:

   $ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git

2. Create the application:

   $ oc create -f openshift-gitops-getting-started/argo/app.yaml

3. Run the oc get command to review the created application:

   $ oc get application -n openshift-gitops

4. Add a label to the namespace your application is deployed in so that the Argo CD instance in the openshift-gitops namespace can manage it:

   $ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops

Procedure

1. Get the admin account password for the Argo CD server:

   $ ADMIN_PASSWD=$(oc get secret openshift-gitops-cluster -n openshift-gitops -o jsonpath='{.data.admin\.password}' | base64 -d)

2. Get the Argo CD server URL:

   $ SERVER_URL=$(oc get routes openshift-gitops-server -n openshift-gitops -o jsonpath='{.status.ingress[0].host}')

3. Log in to the Argo CD server by using the admin account password and enclosing it in single quotes:

   Important

   Enclosing the password in single quotes ensures that special characters, such as $, are not misinterpreted by the shell. Always use single quotes to enclose the literal value of the password.

   $ argocd login --username admin --password ${ADMIN_PASSWD} ${SERVER_URL}

   Example

   $ argocd login --username admin --password '<password>' openshift-gitops.openshift-gitops.apps-crc.testing

4. Verify that you are able to run argocd commands in the default mode by listing all applications:

   $ argocd app list

   If the configuration is correct, then existing applications will be listed with the following header:

   Sample output

   NAME CLUSTER NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO PATH TARGET

5. Create an application in the default mode:

   $ argocd app create app-cluster-configs \
       --repo https://github.com/redhat-developer/openshift-gitops-getting-started.git \
       --path cluster \
       --revision main \
       --dest-server  https://kubernetes.default.svc \
       --dest-namespace spring-petclinic \
       --directory-recurse \
       --sync-policy none \
       --sync-option Prune=true \
       --sync-option CreateNamespace=true

6. Label the spring-petclinic destination namespace to be managed by the openshif-gitops Argo CD instance:

   $ oc label ns spring-petclinic "argocd.argoproj.io/managed-by=openshift-gitops"

7. List the available applications to confirm that the application is created successfully:

   $ argocd app list

   Even though the cluster-configs Argo CD application has the Healthy status, it is not automatically synced due to its none sync policy, causing it to remain in the OutOfSync status.

Procedure

1. Log in to the OpenShift Container Platform cluster by using the oc CLI tool:

   $ oc login -u <username> -p <password> <server_url>

   Example

   $ oc login -u kubeadmin -p '<password>' https://api.crc.testing:6443

2. Check whether the context is set correctly in the kubeconfig file:

   $ oc config current-context

3. Set the default namespace of the current context to openshift-gitops:

   $ oc config set-context --current --namespace openshift-gitops

4. Set the following environment variable to override the Argo CD component names:

   $ export ARGOCD_REPO_SERVER_NAME=openshift-gitops-repo-server

5. Verify that you are able to run argocd commands in core mode by listing all applications:

   $ argocd app list --core

   If the configuration is correct, then existing applications will be listed with the following header:

   Sample output

   NAME CLUSTER NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO PATH TARGET

6. Create an application in core mode:

   $ argocd app create app-cluster-configs --core \
       --repo https://github.com/redhat-developer/openshift-gitops-getting-started.git \
       --path cluster \
       --revision main \
       --dest-server  https://kubernetes.default.svc \
       --dest-namespace spring-petclinic \
       --directory-recurse \
       --sync-policy none \
       --sync-option Prune=true \
       --sync-option CreateNamespace=true

7. Label the spring-petclinic destination namespace to be managed by the openshif-gitops Argo CD instance:

   $ oc label ns spring-petclinic "argocd.argoproj.io/managed-by=openshift-gitops"

8. List the available applications to confirm that the application is created successfully:

   $ argocd app list --core

   Even though the cluster-configs Argo CD application has the Healthy status, it is not automatically synced due to its none sync policy, causing it to remain in the OutOfSync status.

Procedure

1. In the Argo CD dashboard, notice that the cluster-configs Argo CD application has the statuses Missing and OutOfSync. Because the application was configured with a manual sync policy, Argo CD does not sync it automatically.
2. Click SYNC on the cluster-configs tile, review the changes, and then click SYNCHRONIZE. Argo CD will detect any changes in the Git repository automatically. If the configurations are changed, Argo CD will change the status of the cluster-configs to OutOfSync. You can modify the synchronization policy for Argo CD to automatically apply changes from your Git repository to the cluster.
3. Notice that the cluster-configs Argo CD application now has the statuses Healthy and Synced. Click the cluster-configs tile to check the details of the synchronized resources and their status on the cluster.
4. Navigate to the OpenShift Container Platform web console and click to verify that a link to the Red Hat Developer Blog - Kubernetes is now present there.

5. Navigate to the Project page and search for the spring-petclinic namespace to verify that it has been added to the cluster.

   Your cluster configurations have been successfully synchronized to the cluster.

Procedure

1. Get the admin account password for the Argo CD server:

   $ ADMIN_PASSWD=$(oc get secret openshift-gitops-cluster -n openshift-gitops -o jsonpath='{.data.admin\.password}' | base64 -d)

2. Get the Argo CD server URL:

   $ SERVER_URL=$(oc get routes openshift-gitops-server -n openshift-gitops -o jsonpath='{.status.ingress[0].host}')

3. Log in to the Argo CD server by using the admin account password and enclosing it in single quotes:

   Important

   Enclosing the password in single quotes ensures that special characters, such as $, are not misinterpreted by the shell. Always use single quotes to enclose the literal value of the password.

   $ argocd login --username admin --password ${ADMIN_PASSWD} ${SERVER_URL}

   Example

   $ argocd login --username admin --password '<password>' openshift-gitops.openshift-gitops.apps-crc.testing

4. Because the application is configured with the none sync policy, you must manually trigger the sync operation:

   $ argocd app sync openshift-gitops/app-cluster-configs

5. List the application to confirm that the application has the Healthy and Synced statuses:

   $ argocd app list

Procedure

1. Log in to the OpenShift Container Platform cluster by using the oc CLI tool:

   $ oc login -u <username> -p <password> <server_url>

   Example

   $ oc login -u kubeadmin -p '<password>' https://api.crc.testing:6443

2. Check whether the context is set correctly in the kubeconfig file:

   $ oc config current-context

3. Set the default namespace of the current context to openshift-gitops:

   $ oc config set-context --current --namespace openshift-gitops

4. Set the following environment variable to override the Argo CD component names:

   $ export ARGOCD_REPO_SERVER_NAME=openshift-gitops-repo-server

5. Because the application is configured with the none sync policy, you must manually trigger the sync operation:

   $ argocd app sync --core openshift-gitops/app-cluster-configs

6. List the application to confirm that the application has the Healthy and Synced statuses:

   $ argocd app list --core

Procedure

1. In the web console, select User Management → Roles → Create Role. Use the following ClusterRole YAML template to add rules to specify the additional permissions.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secrets-cluster-role
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["*"]

2. Click Create to add the cluster role.
3. To create the cluster role binding, select User Management → Role Bindings → Create Binding.
4. Select All Projects from the Project list.
5. Click Create binding.
6. Select Binding type as Cluster-wide role binding (ClusterRoleBinding).
7. Enter a unique value for the RoleBinding name.
8. Select the newly created cluster role or an existing cluster role from the drop-down list.

9. Select the Subject as ServiceAccount and the provide the Subject namespace and name.

   1. Subject namespace: openshift-gitops

   2. Subject name: openshift-gitops-argocd-application-controller

      Note

      The value of Subject name depends on the GitOps control plane components for which you create the cluster roles and cluster role bindings.

10. Click Create. The YAML file for the ClusterRoleBinding object is as follows:

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: cluster-role-binding
    subjects:
      - kind: ServiceAccount
        name: openshift-gitops-argocd-application-controller
        namespace: openshift-gitops
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: secrets-cluster-role

Procedure

1. In the Argo CD CR, set the value of the .spec.defaultClusterScopedRoleDisabled field to true:

   Example Argo CD CR

   apiVersion: argoproj.io/v1beta1
   kind: ArgoCD
   metadata:
     name: example 1
     namespace: spring-petclinic 2
   # ...
   spec:
     defaultClusterScopedRoleDisabled: true 3
   # ...

   1

   The name of the cluster-scoped instance.

   2

   The namespace where you want to run the cluster-scoped instance.

   3

   The flag value that disables the creation of the default cluster roles for the cluster-scoped instance. If you want the Operator to recreate the default cluster roles and cluster role bindings for the cluster-scoped instance, set the field value to false.

   Sample output

   argocd.argoproj.io/example configured

2. Verify that the Red Hat OpenShift GitOps Operator has deleted the default cluster roles and cluster role bindings for the GitOps control plane components by running the following commands:

   $ oc get ClusterRoles/<argocd_name>-<argocd_namespace>-<control_plane_component>

   $ oc get ClusterRoleBindings/<argocd_name>-<argocd_namespace>-<control_plane_component>

   Sample output

   No resources found

   The default cluster roles and cluster role bindings for the cluster-scoped instance are not created. As a cluster administrator, you can now create and customize permissions for cluster-scoped instances by creating new cluster roles and cluster role bindings for the GitOps control plane components.

Procedure

1. Open the Administrator perspective of the web console and go to User Management → Roles → Create Role.

2. Use the following ClusterRole YAML template to add rules to specify the additional permissions.

   Example cluster role YAML template

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: example-spring-petclinic-argocd-application-controller 1
   rules:
     - verbs:
         - get
         - list
         - watch
       apiGroups:
         - '*'
       resources:
         - '*'
     - verbs:
         - '*'
       apiGroups:
         - ''
       resources: 2
         - namespaces
         - persistentvolumes

   1

   The name of the cluster role according to the <argocd_name>-<argocd_namespace>-<control_plane_component> naming convention.

   2

   The resources to which you want to grant permissions at the cluster level.

3. Click Create to add the cluster role.

4. Find the service account used by the control plane component you are customizing permissions for, by performing the following steps:

   1. Go to Workloads → Pods.
   2. From the Project list, select the project where the user-defined cluster-scoped instance is installed.
   3. Click the pod of the control plane component and go to the YAML tab.
   4. Find the spec.ServiceAccount field and note the service account.
5. Go to User Management → RoleBindings → Create binding.
6. Click Create binding.
7. Select Binding type as Cluster-wide role binding (ClusterRoleBinding).
8. Enter a unique value for RoleBinding name by following the <argocd_name>-<argocd_namespace>-<control_plane_component> naming convention.
9. Select the newly created cluster role from the drop-down list for Role name.

10. Select the Subject as ServiceAccount and the provide the Subject namespace and name.

    1. Subject namespace: spring-petclinic

    2. Subject name: example-argocd-application-controller

       Note

       For Subject name, ensure that the value you configure is the same as the value of the spec.ServiceAccount field of the control plane component you are customizing permissions for.

11. Click Create.

    You have created the required permissions for the control plane component’s service account and namespace. The YAML file for the ClusterRoleBinding object looks similar to the following example:

    Example YAML file for a cluster role binding

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: example-spring-petclinic-argocd-application-controller
    subjects:
      - kind: ServiceAccount
        name: example-argocd-application-controller
        namespace: spring-petclinic
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: example-spring-petclinic-argocd-application-controller

1. Enabling the creation of aggregated cluster roles
2. Creating user-defined cluster roles and configuring user-defined permissions for Application Controller

Procedure

1. In the Argo CD CR, set the value of the .spec.aggregatedClusterRoles field to true:

   Example Argo CD CR

   apiVersion: argoproj.io/v1beta1
   kind: ArgoCD
   metadata:
     name: example 1
     namespace: spring-petclinic 2
   # ...
   spec:
     aggregatedClusterRoles: true 3
   # ...

   1

   The name of the cluster-scoped instance.

   2

   The namespace where you want to run the cluster-scoped instance.

   3

   The value set to true enables the creation of aggregated cluster roles. If you do not want to enable the creation of aggregated cluster roles, either do not include this line or set the value to false.

   Example output

   argocd.argoproj.io/example configured

2. Verify that the Status field of the cluster-scoped Argo CD instance shows as Phase: Available by running the following command:

   $ oc describe argocd.argoproj.io/example -n spring-petclinic

   Example output

   Name:         example
   Namespace:    spring-petclinic
   Labels:       <none>
   Annotations:  <none>
   API Version:  argoproj.io/v1beta1
   Kind:         ArgoCD
   Metadata:
     Creation Timestamp:  2024-08-14T08:20:53Z
     Finalizers:
       argoproj.io/finalizer
     Generation:        3
     Resource Version:  60437
     UID:               57940e54-d60b-4c1a-bc4a-85c81c63ab69
   Spec:
     Aggregated Cluster Roles:  true
   ...
   Status:
     Application Controller:      Running
     Application Set Controller:  Unknown
     Phase:                       Available 1
     Redis:                       Running
     Repo:                        Running
     Server:                      Running
     Sso:                         Unknown
   Events:                        <none>

   1

   The Available status indicates that the cluster-scoped Argo CD instance is healthy and available.

   Note

   The Red Hat OpenShift GitOps Operator creates the following default cluster roles and manages them:

   • <argocd_name>-<argocd_namespace>-argocd-application-controller aggregated cluster role
   • <argocd_name>-<argocd_namespace>-argocd-application-controller-view
   • <argocd_name>-<argocd_namespace>-argocd-application-controller-admin

3. Verify that the Operator has created the default cluster roles and cluster role bindings for the Argo CD Application Controller and Argo CD server components by running the following commands:

   $ oc get ClusterRoles -l app.kubernetes.io/part-of=argocd

   Example output

   NAME                                                           CREATED AT
   example-spring-petclinic-argocd-application-controller         2024-08-14T08:20:58Z
   example-spring-petclinic-argocd-application-controller-admin   2024-08-14T09:08:38Z
   example-spring-petclinic-argocd-application-controller-view    2024-08-14T09:08:38Z
   example-spring-petclinic-argocd-server                         2024-08-14T08:20:59Z

   $ oc get ClusterRoleBindings -l app.kubernetes.io/part-of=argocd

   Example output

   NAME                                                     ROLE                                                                 AGE
   example-spring-petclinic-argocd-application-controller   ClusterRole/example-spring-petclinic-argocd-application-controller   54m
   example-spring-petclinic-argocd-server                   ClusterRole/example-spring-petclinic-argocd-server                   54m

   The cluster role bindings for the view and admin cluster roles are not created. This is because the view and admin cluster roles only add permissions to the aggregated cluster role and do not directly configure permissions to the Argo CD Application Controller.

   Tip

   Alternatively, you can use the OpenShift Container Platform web console to verify from the Administrator perspective. You can go to User Management → Roles and User Management → RoleBindings, respectively. You can search for the cluster roles and cluster role bindings that have the app.kubernetes.io/part-of:argocd label.

4. Verify that the aggregated cluster role is created by checking the permissions of outputs of the roles created by running the following command:

   $ oc get ClusterRole/<cluster_role_name> -o yaml 1

   1

   Replace <cluster_role_name> with the name of the role created.

   Example output of the aggregated cluster role

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     annotations:
       argocds.argoproj.io/name: example
       argocds.argoproj.io/namespace: spring-petclinic
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"argoproj.io/v1beta1","kind":"ArgoCD","metadata":{"annotations":{},"name":"example","namespace":"spring-petclinic"},"spec":{"aggregatedClusterRoles":true}}
       rbac.authorization.kubernetes.io/autoupdate: "true"
     creationTimestamp: "2024-08-14T08:20:58Z"
     labels:
       app.kubernetes.io/managed-by: spring-petclinic
       app.kubernetes.io/name: example
       app.kubernetes.io/part-of: argocd
     name: example-spring-petclinic-argocd-application-controller 1
     resourceVersion: "78640"
     uid: aeeb2ef5-b531-4fe3-a61a-b5ad8dd8ca6e
   aggregationRule: 2
     clusterRoleSelectors:
     - matchLabels:
         app.kubernetes.io/managed-by: spring-petclinic
         argocd/aggregate-to-controller: "true"
   rules: [] 3

   1

   The name of the aggregated cluster role.

   2

   The predefined list of labels indicates that the aggregated cluster role can inherit permissions from the other user-defined cluster roles.

   3

   No predefined permissions are set. However, when the Operator immediately creates a <argocd_name>-<argocd_namespace>-argocd-application-controller-view cluster role, the corresponding predefined view permissions are added into the aggregated cluster role.

   Example output of the view cluster role

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     annotations:
       argocds.argoproj.io/name: example
       argocds.argoproj.io/namespace: spring-petclinic
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"argoproj.io/v1beta1","kind":"ArgoCD","metadata":{"annotations":{},"name":"example","namespace":"spring-petclinic"},"spec":{"aggregatedClusterRoles":true}}
     creationTimestamp: "2024-08-14T09:59:14Z"
     labels: 1
       app.kubernetes.io/managed-by: spring-petclinic
       app.kubernetes.io/name: example
       app.kubernetes.io/part-of: argocd
       argocd/aggregate-to-controller: "true"
     name: example-spring-petclinic-argocd-application-controller-view 2
     resourceVersion: "78639"
     uid: 068b8867-7a0c-4af3-a17a-0560a00eba41
   rules: 3
   - apiGroups:
     - '*'
     resources:
     - '*'
     verbs:
     - get
     - list
     - watch
   - nonResourceURLs:
     - '*'
     verbs:
     - get
     - list

   1

   The labels match the predefined list of an existing aggregated cluster role.

   2

   The name of the view cluster role.

   3

   The predefined view permissions. These permissions are added into the existing aggregated cluster role.

   Example output of the admin cluster role

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     annotations:
       argocds.argoproj.io/name: example
       argocds.argoproj.io/namespace: spring-petclinic
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"argoproj.io/v1beta1","kind":"ArgoCD","metadata":{"annotations":{},"name":"example","namespace":"spring-petclinic"},"spec":{"aggregatedClusterRoles":true}}
       rbac.authorization.kubernetes.io/autoupdate: "true"
     creationTimestamp: "2024-08-14T09:59:15Z"
     labels: 1
       app.kubernetes.io/managed-by: spring-petclinic
       app.kubernetes.io/name: example
       app.kubernetes.io/part-of: argocd
       argocd/aggregate-to-controller: "true"
     name: example-spring-petclinic-argocd-application-controller-admin 2
     resourceVersion: "78642"
     uid: e2d35b6f-0832-4993-8b24-915a725454f9
   aggregationRule: 3
     clusterRoleSelectors:
     - matchLabels:
         app.kubernetes.io/managed-by: spring-petclinic
         argocd/aggregate-to-admin: "true"
   rules: null 4

   1

   The labels match the predefined list of an existing aggregated cluster role.

   2

   The name of the admin cluster role.

   3

   The predefined list of labels indicates that the existing <argocd_name>-<argocd_namespace>-argocd-application-controller-admin cluster role can inherit permissions from the other user-defined cluster roles.

   4

   Specifies that no permissions are defined yet in one or more user-defined cluster roles.

   Tip

   Alternatively, you can use the OpenShift Container Platform web console to verify from the Administrator perspective. You can go to User Management → Roles, use the Filter option, select Cluster-wide Roles, and search for the aggregated cluster role, view, and admin cluster roles. You must open the cluster role to check the details and configurations.

   As a cluster administrator, you can now create one or more user-defined cluster roles and configure user-defined permissions for Argo CD Application Controller.

Procedure

1. Create a new cluster role with the required labels and permissions by using the following command:

   $ oc apply -n <namespace> -f <cluster_role_name>.yaml

   where:

   <namespace>

   Specifies the name of your defined namespace.

   <cluster_role_name>

   Specifies the name of your defined cluster role YAML file.

   Example user-defined cluster role YAML

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: user-application-controller 1
     labels: 2
       app.kubernetes.io/managed-by: spring-petclinic
       app.kubernetes.io/name: example
       app.kubernetes.io/part-of: argocd
       argocd/aggregate-to-admin: 'true'
   rules: 3
     - verbs:
         - '*'
       apiGroups:
         - ''
       resources:
         - namespaces
         - persistentvolumeclaims
         - persistentvolumes
         - configmaps
     - verbs:
         - '*'
       apiGroups:
         - compliance.openshift.io
       resources:
         - scansettingbindings

   1

   The name of the user-defined cluster role.

   2

   The labels match the predefined list of an existing <argocd_name>-<argocd_namespace>-argocd-application-controller-admin cluster role.

   3

   The user-defined permissions that are to be added into the aggregated cluster role through the <argocd_name>-<argocd_namespace>-argocd-application-controller-admin cluster role.

   Tip

   Alternatively, you can use the web console to create a user-defined cluster role from the Administrator perspective. You can go to User Management → Roles → Create Role, use the preceding YAML template to add permissions, and click Create.

   Example output

   clusterrole.rbac.authorization.k8s.io/user-application-controller created

   A user-defined cluster role is created.

2. Verify that the <argocd_name>-<argocd_namespace>-argocd-application-controller-admin cluster role inherits permissions from the user-defined cluster role by running the following command:

   $ oc get ClusterRole/<argocd_name>-<argocd_namespace>-argocd-application-controller-admin -o yaml

   where:

   <argocd_name>

   Specifies the name of your user-defined cluster-scoped Argo CD instance.

   <argocd_namespace>

   Specifies the namespace where Argo CD is installed.

   Example output

   aggregationRule:
     clusterRoleSelectors:
     - matchLabels:
         app.kubernetes.io/managed-by: spring-petclinic
         argocd/aggregate-to-admin: "true"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     annotations:
       argocds.argoproj.io/name: example
       argocds.argoproj.io/namespace: spring-petclinic
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"argoproj.io/v1beta1","kind":"ArgoCD","metadata":{"annotations":{},"name":"example","namespace":"spring-petclinic"},"spec":{"aggregatedClusterRoles":true}}
     creationTimestamp: "2024-08-14T09:59:15Z"
     labels:
       app.kubernetes.io/managed-by: spring-petclinic
       app.kubernetes.io/name: example
       app.kubernetes.io/part-of: argocd
       argocd/aggregate-to-controller: "true"
     name: example-spring-petclinic-argocd-application-controller-admin
     resourceVersion: "79202"
     uid: e2d35b6f-0832-4993-8b24-915a725454f9
   rules:
   - apiGroups:
     - ""
     resources:
     - namespaces
     - persistentvolumeclaims
     - persistentvolumes
     - configmaps
     verbs:
     - '*'
   - apiGroups:
     - compliance.openshift.io
     resources:
     - scansettingbindings
     verbs:
     - '*'

   Tip

   Alternatively, you can use the OpenShift Container Platform web console to verify from the Administrator perspective. You can go to User Management → Roles, use the Filter option, select Cluster-wide Roles, and search for the <argocd_name>-<argocd_namespace>-argocd-application-controller-admin cluster role. You must open the cluster role to check the details and configurations.

3. Verify that the <argocd_name>-<argocd_namespace>-argocd-application-controller aggregated cluster role inherits permissions from the <argocd_name>-<argocd_namespace>-argocd-application-controller-admin and <argocd_name>-<argocd_namespace>-argocd-application-controller-view cluster roles by running the following command:

   $ oc get ClusterRole/<argocd_name>-<argocd_namespace>-argocd-application-controller -o yaml

   where:

   <argocd_name>

   Specifies the name of your user-defined cluster-scoped Argo CD instance.

   <argocd_namespace>

   Specifies the namespace where Argo CD is installed.

   Example output of the aggregated cluster role

   aggregationRule:
     clusterRoleSelectors:
     - matchLabels:
         app.kubernetes.io/managed-by: spring-petclinic
         argocd/aggregate-to-controller: "true"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     annotations:
       argocds.argoproj.io/name: example
       argocds.argoproj.io/namespace: spring-petclinic
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"argoproj.io/v1beta1","kind":"ArgoCD","metadata":{"annotations":{},"name":"example","namespace":"spring-petclinic"},"spec":{"aggregatedClusterRoles":true}}
       rbac.authorization.kubernetes.io/autoupdate: "true"
     creationTimestamp: "2024-08-14T08:20:58Z"
     labels:
       app.kubernetes.io/managed-by: spring-petclinic
       app.kubernetes.io/name: example
       app.kubernetes.io/part-of: argocd
     name: example-spring-petclinic-argocd-application-controller
     resourceVersion: "79203"
     uid: aeeb2ef5-b531-4fe3-a61a-b5ad8dd8ca6e
   rules:
   - apiGroups:
     - ""
     resources:
     - namespaces
     - persistentvolumeclaims
     - persistentvolumes
     - configmaps
     verbs:
     - '*'
   - apiGroups:
     - compliance.openshift.io
     resources:
     - scansettingbindings
     verbs:
     - '*'
   - apiGroups:
     - '*'
     resources:
     - '*'
     verbs:
     - get
     - list
     - watch
   - nonResourceURLs:
     - '*'
     verbs:
     - get
     - list

   Tip

   Alternatively, you can use the OpenShift Container Platform web console to verify from the Administrator perspective. You can go to User Management → Roles, use the Filter option, select Cluster-wide Roles, and search for the aggregated cluster role. You must open the cluster role to check the details and configurations.