Bug 1972080

Summary:	[RFE] Gatekeeper constraints & constrainttemplates are not removed when a policy no longer applies to a managed cluster
Product:	Red Hat Advanced Cluster Management for Kubernetes	Reporter:	Nicolas Comete <nicolas.comete>
Component:	Gatekeeper	Assignee:	Yu Cao <ycao56>
Status:	CLOSED ERRATA	QA Contact:	Eveline Cai <ecai>
Severity:	medium	Docs Contact:	Christopher Dawson <cdawson>
Priority:	unspecified
Version:	rhacm-2.2.z	CC:	gghezzo
Target Milestone:	---	Flags:	ming: rhacm-2.2.z+
Target Release:	rhacm-2.2.6
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-06-28 23:24:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nicolas Comete 2021-06-15 08:27:19 UTC

Description of the problem:
When a Gatekeeper-based policy no longer applies to a managed cluster (e.g.: placement rule changed or even policy has been deleted), the Gatekeeper constraint and constrainttemplate objects remain unchanged, so the Gatekeeper admission hook / audit is still active.

Release version: 2.2.3 with Gatekeeper Operator 0.1.2

Steps to reproduce:
1. Create a Gatekeeper policy (e.g. the one on pages 58-59-60 of the "Red Hat Advanced Cluster Management for Kubernetes 2.2" PDF doc and make sure that the placement rule for the policy applies to one of your managed cluster 
2. On the managed cluster where policy applies, create an action that will be blocked by your Gatekeeper policy (e.g. create a namespace without required label)
3. Change the placement rule for the policy so that the policy will no longer apply to any managed cluster
4. On the same managed cluster as for step 2, create an action that will be blocked by your Gatekeeper policy (e.g. create a namespace without required label)

Actual results:
1. Policy is created and applies to at least on managed cluster
2. Action is denied by Gatekeeper
3. The policy no longer applies to any cluster
4. Action is denied by Gatekeeper

Expected results:
1. Policy is created and applies to at least on managed cluster
2. Action is denied by Gatekeeper
3. The policy no longer applies to any cluster
4. Action is accepted

Comment 1 Mike Ng 2021-06-16 13:56:28 UTC

G2Bsync 862319456 comment 
 gparvin Wed, 16 Jun 2021 12:00:13 UTC 
 G2Bsync Thanks for taking the time to explain your desired behavior.  In this case the policy is behaving as expected.  In order to clean up any gatekeeper policies you can always change the "complianceType" from "musthave" to "mustnothave".  For policies that were being enforced, this will do the clean up that you wanted to see.  Please let me know if you have additional questions.

Comment 5 Nicolas Comete 2021-06-22 07:32:00 UTC

Thanks for your answer.
The context is the following: admin creates a Gatekeeper policy with a placement rule (based on cluster label for instance) that enables the policy on a managed cluster, therefore creating the GK constraints & constraint templates.
Then, if for whatever reason (placement rule is updated, cluster labels change...) the policy no longer applies to the managed cluster.
I find it confusing for admins who can see that the Gatekeeper policy in NOT applying to on the managed cluster, but since the constraint / constraint templates are not removed, practically, policy is still active.
I don't quite see how changing the complianceType would help here - can you please clarify ?

Comment 6 Ginny Ghezzo 2021-06-23 16:48:21 UTC

This is not a straight forward change. I would like to make this an RFE and assure our Product Managers can provide a complete solution.

Comment 10 errata-xmlrpc 2021-06-28 23:24:27 UTC

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 (Red Hat Advanced Cluster Management 2.2.5 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/RHBA-2021:2558