Created attachment 1915047 [details] git repo .zip Description of the problem: Policies using a different order for a list of elements in the description of the apiGroups for a ClusterRole cause a different behaviour - a change between identifying a violation or not. Release version: RHACM 2.5.1 Operator snapshot version: OCP version: 4.8.17 Browser Info: Steps to reproduce: 1. Clone the repository with the manifests and the policy generator $ git clone -b case03319296 git:giovannisciortino/rhacm-policygen.git ./rhacm-policygen_branch_case03319296 2. Manualy create on the local cluster where ACM is installed the clusterrole resources that will be checked by the ACM inform policy $ find ./rhacm-policygen_branch_case03319296/inform-manifests-case03319296/*.yaml |xargs -I MANIFEST_FILE oc create -f MANIFEST_FILE clusterrole.rbac.authorization.k8s.io/developer-a created clusterrole.rbac.authorization.k8s.io/developer-b created clusterrole.rbac.authorization.k8s.io/developer-c created clusterrole.rbac.authorization.k8s.io/developer-d created clusterrole.rbac.authorization.k8s.io/developer-original created 3. Create the inform policy using a policy generator $ oc create -f ./rhacm-policygen_branch_case03319296/policy-subscription.yaml 4. Verify the list of policy violation generated by the policy generator created in the previous step using the web browser trough the url https://acmui.example.com/multicloud/governance/policies/details/policies/pol-gen-inform-lab01-configurations-case03319296/template/local-cluster/policy.open-cluster-management.io/v1/ConfigurationPolicy/pol-gen-inform-lab01-configurations-case03319296 Actual results: developer-a - Violations Resource found but does not match developer-b - No violations Resource found as expected developer-c - No violations Resource found as expected developer-d - No violations Resource found as expected developer-original - Violations Resource found but does not match Expected results: We should see the same behaviour everywhere, where No violations for the resource (ClusterRole) is found. Additional info: there are 7 manifest files in the repository () : - developer-original.yaml : This is exactly the clusterrole causing the issue on the customer environment, only renamed the clusterrole to remove the customer name - developer-a.yaml : This is a clusterrole cloned from developer-original.yaml where the cluster role name has been renamed in "developer-a". It contains only a minimal subset of the cluster role "developer-original" but the issue is still present - developer-b.yaml : This is a clusterrole cloned from developer-original.yaml where the cluster role name has been renamed in "developer-b". It does not contain the apiGroups section that was identified as causing the issue. - developer-c.yaml : This is a clusterrole cloned from developer-original.yaml where the cluster role name has been renamed in "developer-c". It contains in the spec section only the following section(the difference between clusterrole developer-a and developer-b), aka : ~~~ - apiGroups: - apps.openshift.io - "" resources: - deploymentconfigs/scale verbs: - update ~~~ - developer-d.yaml : This is a clusterrole cloned from developer-a.yaml where the cluster role name has been renamed in "developer-d". It contains exactly the same content of developer-a but the lines 38 and 39 have been inverted compared to developer-a clusterrole : ~~~ *** 35,42 **** verbs: - update - apiGroups: - - apps.openshift.io - "" resources: - deploymentconfigs/scale verbs: --- 35,42 ---- verbs: - update - apiGroups: - "" + - apps.openshift.io resources: - deploymentconfigs/scale verbs: ~~~ see https://github.com/giovannisciortino/rhacm-policygen/tree/case03319296/inform-manifests-case03319296 ; I'm also attaching a zip of the repo.
G2Bsync 1284384852 comment oafischer Wed, 19 Oct 2022 18:02:52 UTC G2Bsync Can someone provide a brief summary of this fix? Thanks!
G2Bsync 1284390158 comment mprahl Wed, 19 Oct 2022 18:08:07 UTC G2Bsync This fixes a bug that would cause an `inform` `musthave` `ConfigurationPolicy` to incorrectly say certain `Role` or `ClusterRole` objects were non-compliant. This also improves the `enforce` behavior in these situations.
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: Red Hat Advanced Cluster Management 2.6.2 security update and bug fixes), 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-2022:7313