Describe the solution you'd like
I would like to be able to trigger an on-demand audit scan to reduce latency between policy application and compliance data reporting for that policy. I would also like to monitor the audit scan's status to know when it has completed. A new AuditTrigger custom resource would enable me to define a desired timestamp for my next audit. The audit scan should still run at least every --audit-interval seconds, but this custom resource would enable me to shift the schedule to an earlier offset starting at the time I update the resource's generation. For observation of audit status, I would like at least two conditions in the AuditTrigger status, Acknowledged and ScanCompleted, with the following properties:
Condition | State | Meaning
Acknowledged | Unknown | observedGeneration put on this resource may not yet have been acked
Acknowledged | True | observedGeneration audit trigger has been acked
Acknowledged | False | <Shouldn't occur>
Succeeded | Unknown | observedGeneration scan is still in progress
Succeeded | True | observedGeneration scan has succeeded
Succeeded | False | observedGeneration scan has failed
I don't think switching the audit loop to a job is a strong solution, because it will introduce heavy API server churn to load synced resources into cache at the start of every audit, and list all constraint templates / constraints. At-rest gatekeeper-audit pod resource usage is not significant.
This is a more extensible version of Audit as soon as all policies are loaded · Issue #2587 · open-policy-agent/gatekeeper that allows fully custom timing of the audit scans, not just when audit pod starts up and loads all policies.
Anything else you would like to add:
Considerations: accidental DOS from too-frequent scanning: we could consider some sort of rate-limiting, but it is already the case that the audit pod could be continually scanning if each audit scan takes longer than --audit-interval so the worse case is the same. Intentional DOS: From a security perspective, the ability to trigger the audit scan will be protected by RBAC on the AuditTrigger resource, and policies can also be introduced to protect the resource even further.
Environment:
- Gatekeeper version:
- Kubernetes version: (use
kubectl version):
Describe the solution you'd like
I would like to be able to trigger an on-demand audit scan to reduce latency between policy application and compliance data reporting for that policy. I would also like to monitor the audit scan's status to know when it has completed. A new
AuditTriggercustom resource would enable me to define a desired timestamp for my next audit. The audit scan should still run at least every--audit-intervalseconds, but this custom resource would enable me to shift the schedule to an earlier offset starting at the time I update the resource's generation. For observation of audit status, I would like at least two conditions in theAuditTriggerstatus,AcknowledgedandScanCompleted, with the following properties:Condition | State | Meaning
Acknowledged | Unknown | observedGeneration put on this resource may not yet have been acked
Acknowledged | True | observedGeneration audit trigger has been acked
Acknowledged | False | <Shouldn't occur>
Succeeded | Unknown | observedGeneration scan is still in progress
Succeeded | True | observedGeneration scan has succeeded
Succeeded | False | observedGeneration scan has failed
I don't think switching the audit loop to a job is a strong solution, because it will introduce heavy API server churn to load synced resources into cache at the start of every audit, and list all constraint templates / constraints. At-rest gatekeeper-audit pod resource usage is not significant.
This is a more extensible version of Audit as soon as all policies are loaded · Issue #2587 · open-policy-agent/gatekeeper that allows fully custom timing of the audit scans, not just when audit pod starts up and loads all policies.
Anything else you would like to add:
Considerations: accidental DOS from too-frequent scanning: we could consider some sort of rate-limiting, but it is already the case that the audit pod could be continually scanning if each audit scan takes longer than --audit-interval so the worse case is the same. Intentional DOS: From a security perspective, the ability to trigger the audit scan will be protected by RBAC on the AuditTrigger resource, and policies can also be introduced to protect the resource even further.
Environment:
kubectl version):