kyverno: [Bug] Background scans emit warning events on conditional anchor mismatch

Kyverno Version

1.7.0

Description

We are running Kyverno v1.6.2 and v1.7.0 in different clusters (aws, gcp and on-premises) and we follow a set of upstream policies from Kyverno docs. Using this policy: https://kyverno.io/policies/other/disallow_localhost_services/disallow_localhost_services/ to disallow localhost externalName on services will emit Warning events for all non-ExternalName type services in all our namespaces. An example message will be:

Warning  PolicyViolation  36m (x3 over 148m)  policy-controller  policy 'no-localhost-service' (Validation) rule 'default' failed. conditional anchor mismatch: resource value 'ClusterIP' does not match 'ExternalName' at path /spec/type/

for kyverno v1.6.2, or

Warning   PolicyViolation policy no-localhost-service/default skip: conditional anchor mismatch: resource value 'ClusterIP' does not match 'ExternalName' at path /spec/type/

for kyverno v1.7.0 Skipping a rule because of conditional anchor mismatch is expected and throwing warnings can be very misleading here. This applies on both audit and enforce validationFailureAction when setting background checks to true.

Slack discussion

No response

Troubleshooting

  • I have read and followed the documentation AND the troubleshooting guide.
  • I have searched other issues in this repository and mine is not recorded.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 2
  • Comments: 23 (6 by maintainers)

Most upvoted comments

This issue also reports removing skipped policies from the events:

https://github.com/kyverno/kyverno/issues/4044

Oh, yeah ! You are right @george-angel . We don’t need to warn here for a simple skip of rule over resource. It’s not a critical message. So, Will it be fine, if we push this Warning message to the log level. I think Info also seems to fit here. But I don’t think debug will be a good choice…

Hey @realshuting , want to confirm one thing. Currently only 2 events are supported, PolicyViolation(for fail/error result) and PolicyApplied(for pass/skip result). As the above issue is demanding to create new type of events for skipped policy, i.e. PolicySkipped(for all skip results) on background(i.e. when background=True) scans. So, do we need to enhance this new event(i.e. PolicySkipped) for non-background scans too. For example: suppose a policy is applied either with enforce/audit mode skips the resource and therefore generates PolicyApplied event. But on enhancing it with new events(i.e. PolicySkipped), it will generate PolicySkipped event instead of PolicyApplied events.

@viveksahu26 - yes, this sounds good to me!

@viveksahu26 thanks for looking into this. Yes, we do not complain about emitting an event as long as it is not a Warning. This should work for us 😃)

@viveksahu26 if PolicySkipped will not apply on any resources or not create any violations for that.

@viveksahu26 yes, changing the event type would be a solution here. Also, in regards to https://github.com/kyverno/kyverno/issues/4044, I think that changing the reason to PolicySkipped also qualifies for changing the event type to Information or Normal, since skipping because of a pre-condition, means that everything works as expected and there is no need to warn

Hello @viveksahu26 I think the crux of the issue is that we think Warning is an incorrect log level for this message, as its describing behaviour that is “working as expected”. Info or Debug would be a more appropriate level for messages that describe normal operation.

yes, if a condition is not met and a rule is skipped this is usually an intentional thing that users should not need to be warned about with kube events. For example this policy: https://kyverno.io/policies/other/disallow_localhost_services/disallow_localhost_services/ should not throw warnings for ClusterIP services, like explained in the description. The end result (in our case) is getting warnings for valid ClusterIP services, where no action is needed.