Based on audit logs of a cluster that has been running for a day: $ cat * | grep '"resource":"rolebindings"' | grep '"verb":"update"' | jq -r '.user.username+"\t->\t "+.objectRef.namespace+":"+.objectRef.name' | sort | uniq -c 3577 system:serviceaccount:openshift-machine-config-operator:default -> default:machine-config-daemon-events 3577 system:serviceaccount:openshift-machine-config-operator:default -> openshift-machine-config-operator:machine-config-daemon-events 320 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> default:prometheus-k8s 320 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> kube-system:prometheus-k8s 321 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> kube-system:resource-metrics-auth-reader 320 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> openshift-apiserver:prometheus-k8s 320 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> openshift-cluster-version:prometheus-k8s 320 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> openshift-etcd:prometheus-k8s 321 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> openshift-kube-controller-manager:prometheus-k8s 321 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> openshift-kube-scheduler:prometheus-k8s 320 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> openshift-monitoring:prometheus-k8s 320 system:serviceaccount:openshift-monitoring:cluster-monitoring-operator -> openshift-monitoring:prometheus-k8s-config 210 system:serviceaccount:openshift-network-operator:default -> openshift-infra:openshift-sdn-controller-account 210 system:serviceaccount:openshift-network-operator:default -> openshift-sdn:openshift-sdn-controller-leaderelection 210 system:serviceaccount:openshift-network-operator:default -> openshift-sdn:prometheus-k8s CMO is continuously updating ten role bindings. It should only update when the role binding is different than the expected value.
Moving to 4.1.z based on discussion w/ Mo. Frederic if there's a quick+low risk fix you can land for this before code freeze for 4.1.0, we'd still take it i think.
I think this should be a fairly quick+low risk fix indeed. We're looking into it.
issue is fixed with payload: 4.1.0-0.nightly-2019-05-09-182710
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0758