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)
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 thelog
level. I thinkInfo
also seems to fit here. But I don’t thinkdebug
will be a good choice…@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 toInformation
orNormal
, since skipping because of a pre-condition, means that everything works as expected and there is no need to warnHello @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
orDebug
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.