Is your feature request related to a problem? Please describe.
For a CREATE using metadata.generateName, the kube-apiserver generates the name after mutating admission runs, so a mutating webhook sees metadata.name === "". A name/regex-scoped binding (.WithName/.WithNameRegex) therefore reports a mismatch and is skipped fail-open, logged only at debug (filter.ts:67-74, mutate-processor.ts:143-160,173-177). Operators get no visible signal that the binding never applied.
This is expected Kubernetes behavior (mutating webhooks aren't guaranteed to see the final object), not a security vulnerability, but the silent skip is surprising.
Describe the solution you'd like
- Given a mutating binding scoped by .WithName/.WithNameRegex
- When it is evaluated against an object with empty metadata.name and a set metadata.generateName
- Then Pepr emits a warn-level log noting the binding was skipped because the name is not yet assigned, and points to using a validating binding for enforcement
Additional context
Originated from a responsibly-disclosed report by @EchoSkorJjj, reviewed and determined not to be a security vulnerability.
Is your feature request related to a problem? Please describe.
For a CREATE using metadata.generateName, the kube-apiserver generates the name after mutating admission runs, so a mutating webhook sees metadata.name === "". A name/regex-scoped binding (.WithName/.WithNameRegex) therefore reports a mismatch and is skipped fail-open, logged only at debug (filter.ts:67-74, mutate-processor.ts:143-160,173-177). Operators get no visible signal that the binding never applied.
This is expected Kubernetes behavior (mutating webhooks aren't guaranteed to see the final object), not a security vulnerability, but the silent skip is surprising.
Describe the solution you'd like
Additional context
Originated from a responsibly-disclosed report by @EchoSkorJjj, reviewed and determined not to be a security vulnerability.