Set Up RBACs on CI Clusters

All the clusters for Openshift CI have enabled authentication via Red Hat SSO. The RBAC manifests defined in the clusters folder of the release repo are applied automatically to the clusters.

Rover Groups

For privacy reasons, we avoid referring to specific usernames in all RBAC manifests stored in the repository. As an enforced convention, users are not allowed to be subjects of the RoleBinding and ClusterRoleBinding manifests: every subject is either a Group or a ServiceAccount. Moreover, each group has to be a Red Hat Rover group or a renamed group from a Rover group via configuration.

For the same privacy reasons, we disallow maintaining Group manifests directly in the repository. Instead, the users need to use the Red Hat’s Rover Groups feature to maintain the list of RH users belonging to a group, and Test Platform tooling will maintain the Group resources on OpenShift CI cluster to contain users corresponding to the Rover group.

Configuration

By default, every group used in the manifests is created on all CI clusters. A configuration file is used to address special cases.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

cluster_groups:
  dp-managed:
  - build01
  - build02
groups:
  test-platform-ci-monitoring-viewers:
    clusters:
    - app.ci
    cluster_groups:
    - dp-managed
    rename_to: ci-monitoring-viewers
  some-invisible-group: {}

• Group renaming: In the above example, the Rover group test-platform-ci-monitoring-viewers is renamed to ci-monitoring-viewers on the clusters.

• Not all clusters: The Rover group test-platform-ci-monitoring-viewers is created on app.ci, and cluster_groups/dp-managed which is composed of build01 and build02.

• some-invisible-group: {} implies that the Rover group some-invisible-group exists on all clusters, even if it is not used by any manifests.

Troubleshooting

No API is provided to create Rover groups. We have to do some manual work on the existing groups and the RBACs with user subjects.

Existing Groups

The existing groups defined in the release repo will be removed from the release repo and the clusters. For example, group/cvp-pool-admins cannot exist any more in the release repo because it contains usernames.

1
2
3
4
5
6
7

apiVersion: user.openshift.io/v1
kind: Group
metadata:
  name: cvp-pool-admins
users:
- bob
- jim

When it is removed from the release repo and the cluster, the members of the group lose the corresponding permissions on the clusters. To retrieve the permissions, we have to modify RBACs in the release repo and/or update the config file.

The most common case is that we can use an existing Rover group, e.g, cvp-team as subjects of RBACs.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cvp-pool-admins
  namespace: cvp-cluster-pool
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: hive-cluster-pool-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: cvp-team ### an existing Rover group

Update the config file with the following stanza because the group is needed only on the hive cluster.

1
2
3
4

groups:
  cvp-team:
    clusters:
    - hive

Optionally the group name on the cluster can be modified by rename_to: If rename_to is not set, the group name on the cluster is the same as the Rover group. Otherwise, the value of rename_to is the group name on the cluster, and thus should be used as a subject of any RoleBinding or RoleBinding such as RoleBinding/cvp-pool-admins above.

1
2
3
4
5

groups:
  cvp-team:
    clusters:
    - hive
  rename_to: cvp-pool-admins

Existing User Subjects

The user subjects will be removed from the existing RBAC manifests. The owner has to modify the manifest to use Rover groups.