-

Backup and Restore SCC Associated with ClusterRole/ClusterRoleBinding
-

What is the nature and description of the request?

• The existing backup and restore of SCCs based on the content of the SCC users field leaves much to be desired and misses the vast majority of custom SCCs needed during backups.

The existing implementation is to check if a ServiceAccount is in the users field of the SCC. https://github.com/openshift/openshift-velero-plugin/blob/oadp-1.5/velero-plugins/serviceaccount/backup.go#L95

This not the recommended method of adding ServiceAccounts to use an SCC since OpenShift 4.6.

The command 'oc adm policy add-user-to-scc' since 4.6 creates a ClusterRole and ClusterRoleBinding with the use verb for the ServiceAccount. As a result, these SCC usually lack any specific users in the user field.

As a result, backup and restore of custom SCC is better triggered off of Pods rather than ServiceAccounts as well as getting a better view of what is in actual use.

The SCC in use of a Pod is location in .metadata.annotations key "openshift.io/scc" and the serviceAccount is also available in the Pod.

The ClusterRole and ClusterRoleBinding associated with ServiceAccounts are already backed up in base Velero OADP-1.5 thanks to `pkg/backup/actions/service_account_action.go`. So no additional ClusterRoles or ClusterRoleBindings need to be searched for.  These ClusterRole and ClusterRoleBindings will typically be named based on the SCC name ic the oc command was used such as 'system:openshift:scc:anyuid '

Why does the customer need this? (List the business requirements here)

• IBM CloudPak4Data is doing backups and restores and has typically relied on the namespace/project uids being restored are trying to get away from that.

Unlike the default SCCs which work because they already exist such as 'nonroot' and 'anyuid', any custom SCC is not backed up and restored when access is given via ClusterRole/ClusterRoleBinding instead of SCC .users field.

Optional: List affected component/s.

Openshift Velero Plugin

Linked Issue:

https://github.ibm.com/ProjectAbell/abell-tracking/issues/68936