Story (Required)

As suggested in the epic, implement the feature to use aggregated cluster roles to allow user to configure.

Approach (Required)

• Install OpenShift GitOps operator.
• Operator creates following default cluster roles with required permissions.
  • Openshift-gitops-openshift-gitops-argocd-application-controller
  • Openshift-gitops-openshift-gitops-argocd-applicationset-controller
  • Openshift-gitops-openshift-gitops-argocd-server
• Out of these three default ClusterRoles, one created for Application Controller (CR 1) is an Aggregated ClusterRole.
• That means App Controller ClusterRole will not have any rules defined, instead it will inherit permissions from other two ClusterRoles, one for view (CR 2) and  other for Admin permissions (CR 3). Both will be created and managed by Operator.
• The CLusterRole for Admin permission (CR 3) is also an aggregated ClusterRole, it means user can create a custom ClusterRole (CR 4) having same label and inject permissions according to their requirements. 
• Here is example
• CR 1 -> Base ClusterRole created by operator for Application controller. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: 
  annotations: 
    rbac.authorization.kubernetes.io/autoupdate: "true"
  name: openshift-gitops-openshift-gitops-application-controller
aggregationRule: 
  clusterRoleSelectors: 
  - matchLabels: 
      gitops/aggregate-to-controller: "true" # rules will be inherited from CR 2 & CR 3
rules: [] 

• CR 2 -> ClusterRole created by operator for Application controller to have View permissions.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: 
  name: gitops-application-controller-view
  labels: 
    gitops/aggregate-to-controller: "true" # rules will be added in CR 1
rules: 
    - verbs: 
      - get
      - list
      - watch
    apiGroups: 
      - '*'
    resources: 
      - '*'
  - verbs: 
      - get
      - list
    nonResourceURLs: 
      - '*'

• CR 3 -> ClusterRole created by operator for Application controller to have permissions over other resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: 
  name: gitops-application-controller-admin
  labels: 
    gitops/aggregate-to-controller: "true" # admin rules inherited from CR4 will be added to CR 1
aggregationRule: 
  clusterRoleSelectors: 
  - matchLabels: 
      gitops/aggregate-to-admin: "true" # rules will be inherited from CR 4.
rules: [] 

• CR 4 -> Custom ClusterRole created by user for Application controller to customize permissions in CR 3.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata: 
  name: user-application-controller
  labels: 
    gitops/aggregate-to-admin: "true"# the rules given below will be added to the CR 3.
 rules: 
  - verbs: 
      - get
      - patch
      - delete
    apiGroups: 
      - '*'
    resources: 
      - '*'
  - verbs: 
      - create
      - get
      - list
      - watch
      - update
      - patch
      - delete
    apiGroups: 
      - ''
    resources: 
      - secrets
      - configmaps
  - verbs: 
      - create
      - get
      - list
      - watch
      - update
      - delete
      - patch
    apiGroups: 
      - argoproj.io
    resources: 
      - applications
      - applicationsets
      - appprojects
  - verbs: 
      - create
      - list
    apiGroups: 
      - ''
    resources: 
      - events
  - verbs: 
      - create
      - update
    apiGroups: 
      - batch
    resources: 
      - jobs
      - cronjobs
      - cronjobs/finalizers 

The hierarchy of ClusterRoles would be something like this.

                                      openshift-gitops-openshift-gitops
                                      -application-controller (CR1)
                                                           | 
          ----------------------------------------------------------------------------------
          |                                                                                                  | 
  gitops-application                                                                       gitops-application
  -controller-view (CR2)                                                                 -controller-admin (CR3)   
                                                                                                              |  
                                                                                                         user-application
                                                                                                          -controller (CR4)

Acceptance Criteria (Mandatory)

1. All existing functionalities work as expected.
2. E2E tests to validate the functionality.