kyverno
kyverno copied to clipboard
[Enhancement] Indicating in a report result the origin, admission or background
Problem Statement
Results in policy reports come from two possible sources: admission reviews or background scans. Depending on the policy/rule, it may not be possible to enable both (ex., a rule which depends on information available during the admissions process like request.userInfo
cannot be enabled for background scans). But in the result for a policy report, this source is not stated.
Solution Description
Indicate somehow, on a per-result basis, the origin of that result: admission or background.
Alternatives
No response
Additional Context
No response
Slack discussion
No response
Research
- [X] I have read and followed the documentation AND the troubleshooting guide.
- [X] I have searched other issues in this repository and mine is not recorded.
Must keep in mind that if a violating resource is observed both at admission time and background scans, the background scan result will overwrite the admission result therefore the source would flip from admission
to background
.
/assign
/assign
@chipzoller Hi! I am new to this project and would like to contribute. I have read the documentation and understood the project a little bit and is currently trying to fix this issue. My one question was that you refer to the PolicyReportResult right?
Yes
@EraKin575 we can probably use the source
field in reports results.
/assign
/assign
@chipzoller @eddycharly for determining the origin of a report, can rule type be a differentiating factor here? As an example, if ruleType == MutationRule || ruleType == GenerationRule
, it means origin is admission else if ruleType == ValidationRule
, it means origin is background? Am i right here? I also found that through spec.background
in a policy , we can find it's origin. Which one should i use to find origin?
The only types of rules presently capable of creating policy report results are validate and verifyImages. You cannot use the spec.background
field to determine where the result was observed unless it is false
, but I don't think that's a good approach.
The only types of rules presently capable of creating policy report results are validate and verifyImages. You cannot use the
spec.background
field to determine where the result was observed unless it isfalse
, but I don't think that's a good approach.
Fine, thanks for clarifying!
@coder12git we switched to EphemeralReport
s in 1.12. There's a label that tells the source of the ephemeral report.
You need to take this source into consideration when aggregating ephemeral reports into policy reports.
@coder12git we switched to
EphemeralReport
s in 1.12. There's a label that tells the source of the ephemeral report.You need to take this source into consideration when aggregating ephemeral reports into policy reports.
@eddycharly can you please point out to that label that tells the source of the ephemeral report? I was not able to find that.
@coder12git we switched to
EphemeralReport
s in 1.12. There's a label that tells the source of the ephemeral report.You need to take this source into consideration when aggregating ephemeral reports into policy reports.
The source field in reports only tell that it is from kyverno.i.e valueKyvernoApp