Description
1. No audit trail for successful mutations
The mutating admission webhook logs "Execute webhook" on entry and logs skips, but when a validation container is actually
injected into a pod — the most security-relevant event the operator performs — there is no log record.
You cannot answer "which pods were injected, with what auth method, by which ModelValidation CR" from the operator's logs today.
This makes incident investigation and compliance auditing impossible.
2. Pod labels leaked at Info level
pod_webhook.go:96 logs "labels", pod.Labels — the entire label map — at Info level on every pod admission. Pod labels
commonly contain team names, environment identifiers, deployment metadata, and business-sensitive tagging. A security operator
should not be dumping this into its logs on every admission request.
Current behavior
- A pod gets injected with a validation container → nothing logged
- Every pod admission → full label map dumped at Info
Expected behavior
- Every injection logged with: pod name, namespace, ModelValidation CR name, auth method, continuous mode, sidecar type
- Only the matching label value logged, not the full label map
Description
1. No audit trail for successful mutations
The mutating admission webhook logs "Execute webhook" on entry and logs skips, but when a validation container is actually
injected into a pod — the most security-relevant event the operator performs — there is no log record.
You cannot answer "which pods were injected, with what auth method, by which ModelValidation CR" from the operator's logs today.
This makes incident investigation and compliance auditing impossible.
2. Pod labels leaked at Info level
pod_webhook.go:96logs"labels", pod.Labels— the entire label map — at Info level on every pod admission. Pod labelscommonly contain team names, environment identifiers, deployment metadata, and business-sensitive tagging. A security operator
should not be dumping this into its logs on every admission request.
Current behavior
Expected behavior