Request: Separate Non-Complaint status to 2 different Types

[tal-hason]

when a policy is created to Enforce remediation and a Non-Compliant change has been created an event is triggered and until the event is acknowledged or deleted the cluster state is Non-Compliant. but the cluster is compliant.

so to get a clearer view of the status of the Non-Compliant cluster it should be separated into 2 types.

1. Cluster Compliant State.
2. Cluster Policy events.

[mikeshng]

CC @mprahl @dhaiducek @JustinKuli

[JustinKuli]

@tal-hason, sorry, I don't quite understand what you're asking. What would be the difference between the two types? I think the cluster compliance state should just be calculated from the "most recent" policy events, so I don't see where there would be a disagreement...

Maybe an example of something I think isn't obvious would help... let's say I have a mustnothave ConfigurationPolicy for an nginx pod, and it's set to Enforce. At first, that pod doesn't exist on the cluster; the policy observes this and so the policy and the cluster are compliant. If I manually create the pod, I expect the policy to "see" it, and become non-compliant. At the same time, since the policy should be enforced, the configuration-policy-controller will try to delete that pod. The policy should stay non-compliant until it observes (after the delete) that the pod is not on the cluster.

[tal-hason]

hi @JustinKuli, thanks for the response.

currently, there is only one state Complaint or Non-Complaint, let's take your example from a different POV.

Let's say I have a policy that enforces a Deployment that can't have a specific image but that deployment was rolled out with an image that met the policy and then somebody tried to change to the restricted image.

the ACM enforce this change and didn't roll out the deployment. but the event was created and on the dashboard, it seems that the cluster is Non-Compliant state, although it is, it has an event where the policy was triggered.

so in the dashboard, the cluster state is false.

the cluster is still compliant because of the policy enforcement, but there is an event that happened and this isn't displayed clearly.

that is why I think there should be 2 types of notifications states:

1. for the cluster-compliant state
2. for events from the policy enforcement

in General, there is a distinct difference between events and status.
events are a point in time of the status and do not always impact the ongoing status of the system.

hope I was clear

[JustinKuli]

@tal-hason I think that does clear it up, thank you!

So I think this changes slightly depending on how it's enforced... in my example with a mustnothave ConfigurationPolicy, I think the replicated policy (on the hub cluster, but in the cluster's namespace) will have a history indicating that the policy became non-compliant, and then compliant, like I described above. But if you used Gatekeeper or something similar to prevent the change, and the policy checked for something like events from Gatekeeper indicating it blocked the change, then the policy might remain non-compliant like you described.

This is a good point:

in General, there is a distinct difference between events and status.
events are a point in time of the status and do not always impact the ongoing status of the system.

When the configuration-policy-controller is used to enforce something directly, the events it makes directly indicate the status of the system at that time. But when a configuration policy sets up and monitors something like Gatekeeper to enforce something, the events on the configpolicy no longer match the system status in the same kind of way.

[JustinKuli]

I feel like having the policy status correspond directly to the cluster status is nice. But it means that actions taken to maintain that status are too easily lost - an admin shouldn't have to look at every history on every policy to see when the configuration policy "enforced" something.

If we separate those events, I guess we'll need a mechanism for specifying each kind of event when they come from other policy engines...

[tal-hason]

Not really, like you have the compliant state ✅ and ❌ for the cluster state.
you can add another one for events.
like Policy trigger events with a ✅ and ❌ that shows there was policy remediation.

so when the admin looks at the cluster Governance Dashboard, he will see 2 signals.

1. for the current state of the cluster, if enforced or not (compliant or non-compliant)
2. events that triggered the policy, and then he can go and approve, ack, or delete those events after he investigates or not.

then the dashboard will have honest transparency of the cluster states and events.

[github-actions]

This issue is stale because it has been open for 120 days with no activity. After 14 days of inactivity, it will be closed. Remove the stable label to prevent this issue from being closed.