Description of problem: RoleBinding and ClusterRoleBinding brought in by kubevirt does not get reconciled when "kind" is "ServiceAccount". 1) Currently the various RoleBindings brought in by KubeVirt [ kubevirt-apiserver, kubevirt-handler, kubevirt-monitoring ] All have the "Subjects" with only "Kind" as "ServiceAccount" 2) All these are probably brought in by virt-operator, if I am not mistaken. Considering 1) and 2) probably we may need to reconcile when "kind" under "subjects" in RoleBinding and ClusterRoleBinding is "ServiceAccount" too. If not RoleBindings and ClusterRoleBindings do not get reconciled. Version-Release number of selected component (if applicable): 4.8.0 How reproducible: Update RoleBindings and/or ClusterRoleBindings "subjects" Steps to Reproduce: 1. Update RoleBindings and/or ClusterRoleBindings "subjects" brought in by kubevirt 2. NOTE: The only "kind" currently under "subjects" is "ServiceAccount" 3. Actual results: RoleBinding and ClusterRoleBinding brought in by kubevirt does not get reconciled when updating "kind" == "ServiceAccount" under "Subjects" Expected results: RoleBinding and ClusterRoleBinding brought in by kubevirt should get reconciled when updating "kind" == "ServiceAccount" under "Subjects" Additional info: Currently only "subjects" with "kind" "Users" are reconciled. Raising this bug to track this issue and see if we also need to reconcile even when "kind" is "ServiceAccount"
Ashley, I know each resource type has specific rules. Is the description of this BZ expected behavior?
Hey everyone, We currently indeed reconcile only subject with "User" kind. This was done intentionally since that's what was done in OpenShift and we were trying to be safe. According to Kubernetes documentation [1] there are 3 subject Kinds: users, groups, and service accounts. I see that we use all three of them and therefore will issue a PR to reconcile all RoleBinding / ClusterRoleBinding unconditionally.
(In reply to Itamar Holder from comment #2) > Hey everyone, > > We currently indeed reconcile only subject with "User" kind. > This was done intentionally since that's what was done in OpenShift and we > were trying to be safe. > > According to Kubernetes documentation [1] there are 3 subject Kinds: users, > groups, and service accounts. I see that we use all three of them and > therefore will issue a PR to reconcile all RoleBinding / ClusterRoleBinding > unconditionally. Forgot to add link to documentation. [1] https://kubernetes.io/docs/reference/access-authn-authz/rbac/
This was deferred to future due to the fact that it takes cluster admin privileges to manipulate this field, which somewhat limits the severity of the impact.
Moving this BZ back to "NEW" state. The associated PR was closed.
I believe this is a mistake that the associated PR was never updated to the correct one. I think this PR https://github.com/kubevirt/kubevirt/pull/5813 was merged to fix this bug and we can move this to modified. @iholder can you confirm?
Yes, @aschuett is absolutely right. Thanks for clarifying! So this needs to be moved to POST again?
Moving the BZ to MODIFIED as the associated PR is merged.
VERIFIED with virt-operator: container-native-virtualization/virt-operator/images/v4.9.0-27
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 (Moderate: OpenShift Virtualization 4.9.0 Images security and bug fix update), 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/RHSA-2021:4104