Targets no longer send pass events as of v3

[helveciofneto]

I'm trying to better understand the reasoning behind the decision for targets not to send pass events in v3?

I see this comment in a closed issue for the Security Hub target and I understand the change from minPriority to minSeverity, but I still failed to understand why that should imply pass events must not even be sent to Targets. I also see this comment on the PR to add a PagerDuty target, but I checked the Security Hub Target code and (as of today) it also seems to filter out anything other than fail, warn or error:

func filterResults(results []v1alpha2.PolicyReportResult) []v1alpha2.PolicyReportResult {
	return helper.Filter(results, func(r v1alpha2.PolicyReportResult) bool {
		if r.Result == v1alpha2.StatusFail {
			return true
		}
		if r.Result == v1alpha2.StatusWarn {
			return true
		}
		if r.Result == v1alpha2.StatusError {
			return true
		}

		return false
	})
}

The reason I'm asking is because I thought receiving pass events was a quick way to close/resolve previous failures on some targets (i.e. Elasticsearch alerts that watch these events coming into the cluster or even the already mentioned incoming PagerDuty target). In such a scenario, policy-reporter would just send whatever event, and the logic to deal with it would be either on the Target or on the final destination. If someone wants to filter out a given status, minSeverity would still be able to handle it.

In case I'm missing some better way to handle event closure regardless of Target, I'm glad to hear about it. Thanks in advance!

[fjogeleit]

Sorry for the late response. IN v3 I decided to no longer send pass events to simplify the logic and behavior.

The use case you describe is not really solid. The reason is that results not always switch from fail to pass, they are also removed in some cases. E.g. the resource will be deleted or the policy. Then the target will never be informed.

SecurityHub has additional logic to request existing entries in SH and updated them when they are change or no longer exist in the report. Other targets likke PageerDuty will need a similar logic to fetch and update items from the target API to have a stable implementation of a synchronization logic.

[helveciofneto]

The use case you describe is not really solid. The reason is that results not always switch from fail to pass, they are also removed in some cases. E.g. the resource will be deleted or the policy. Then the target will never be informed.

Yes, for that it would be necessary to send deleted events as well, so the target could handle it accordingly. This, however, would go against the simplified logic you're after.

I understand now the decisions and the reasoning behind this change. Thanks!