-
Bug
-
Resolution: Done-Errata
-
Normal
-
None
-
False
-
None
-
False
-
NEW
-
VERIFIED
-
Before this change, it was impossible to use non-string values (e.g., .responseStatus.code: 403) in the drop filter. With this update, the drop filter will work correctly with such values.
-
Bug Fix
-
-
Description of problem:
when using drop filter to drop any logs that dont have .responseStatus.code: '403' from audit logs, logs with .responseStatus: 200 and others still get forwarded.
Version-Release number of selected component (if applicable):
5.9.3
How reproducible:
Reproduced
Steps to Reproduce:
Set CLF to:
spec: filters: - drop: - test: - field: .responseStatus.code notMatches: '403' name: audit-log-policy type: drop pipelines: - filterRefs: - audit-log-policy inputRefs: - audit name: hello outputRefs: - default
However, when implementing this, the collectors will still forward logs with .responseStatus.code of 200, for example. I suspect it's an integer vs string issue, because when changing the filter to:
- field: .stage
notMatches: ResponseComplete
or:
- field: .objectRef.namespace
matches: openshift-ingress-operator
The filter works as expected for these. Collector logs dont report error related to filter.
Also tested using `matches` instead of `notMatches` and it also does not match on this. I.e.:
filters: - drop: - test: - field: .responseStatus.code matches: ^200$ name: audit-log-policy type: drop
It still forwards logs with 200.