Description of problem:

rhbz#1821771 added a release note to 4.6 suggesting born-in-4.1 clusters adjust the following ClusterRoleBindings:

• cluster-status-binding
• discovery
• system:basic-user
• system:discovery
• system:openshift:discovery

However, this suggests that those ClusterRoleBindings are created at install-time and subsequently not actively maintained by cluster components. Besides allowing install-time choices to persist indefinitely, this leaves the cluster unable to respond to resource deletion, or users mutating the resources to do other things. If OpenShift doesn't have an opinion on the presence or content of these resources, can we skip creating them at install-time? If OpenShift does have opinions about the presence and/or content of these resources, can we teach an in-cluster component to actively reconcile that target state?

Version-Release number of selected component (if applicable):

At least 4.15 and 4.6. Likely all releases including 4.1.

How reproducible:

Reproduced on the first attempt. I only made one attempt.

Steps to Reproduce:

1. Install a cluster, e.g. with ClusterBot launch 4.15.0-ec.1 aws.
2. Delete one of the impacted ClusterRoleBindings, e.g. oc delete clusterrolebinding system:openshift:discovery.
3. Wait several minutes, or what seems like a reasonable time for a high-latency controller to notice the removal and create a replacement, e.g. sleep 600.
4. Check for the presence of the ClusterRoleBinding, e.g. oc get clusterrolebinding system:openshift:discovery.

Actual results:

$ oc delete clusterrolebinding system:openshift:discovery
clusterrolebinding.rbac.authorization.k8s.io "system:openshift:discovery" deleted
$ sleep 600
$ oc get clusterrolebinding system:openshift:discovery
Error from server (NotFound): clusterrolebindings.rbac.authorization.k8s.io "system:openshift:discovery" not found

Expected results:

Either the initial delete fails on does-not-exist (if we decide to stop installing the ClusterRoleBinding), or the subsequent get succeeds (if we decide to actively manage the ClusterRoleBinding).

Also, if we decide to stop installing the ClusterRoleBinding, we probably want an plan for the existing clusters where we already created the resource. Do we want to delete the resources when we update out? Do we want an admin-ack so that admins have to say "yes, I read the KCS about how you're moving away from those resources, and I have to decide if I want to take responsibility for maintaining them or delete them"? Something else?