-
Bug
-
Resolution: Done-Errata
-
Normal
-
None
-
False
-
-
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.