feat(helm): Add configurable reinvocationPolicy for MutatingWebhookConfiguration

[EscobozaEstrada]

Summary

This PR introduces support for configuring the reinvocationPolicy field on the Falcon Sensor MutatingWebhookConfiguration resource via a new Helm value. The default behavior (Never) is preserved, maintaining full backward compatibility.

---

Motivation

In clusters running multiple mutating admission webhooks — such as Kyverno or OPA Gatekeeper — webhook execution ordering can result in scenarios where a subsequent webhook modifies a Pod after the Falcon Injector has already evaluated it. In such cases, Kubernetes does not automatically re-invoke earlier webhooks, which can cause the Falcon sensor sidecar to be omitted from the final Pod spec.

The Injection Annotation Problem

A concrete and common example of this is the Falcon injection opt-in annotation:

sensor.falcon-system.crowdstrike.com/injection: enabled

Some teams use policy controllers (e.g., Kyverno ClusterPolicy or OPA AssignMetadata) to dynamically add this annotation to Pods at admission time — rather than hardcoding it in every workload manifest. However, if the policy controller's webhook runs after the Falcon webhook, the following race condition occurs:

1. Pod admission request arrives at the Falcon webhook.
2. Falcon evaluates the Pod — the annotation is not yet present — and skips injection.
3. The policy controller's webhook runs and adds the annotation.
4. Kubernetes does not re-invoke the Falcon webhook; the sidecar is never injected.

Setting reinvocationPolicy: IfNeeded resolves this by instructing the Kubernetes API server to re-invoke the Falcon webhook whenever a later admission controller mutates the object, ensuring the annotation is visible during Falcon's evaluation.

The Kubernetes reinvocationPolicy: IfNeeded setting instructs the API server to re-invoke a webhook if the object is mutated by a later admission controller. Exposing this field as a configurable Helm value allows operators to opt into this behavior without requiring manual patch operations on the webhook resource.

This is particularly relevant in Amazon Elastic Kubernetes Service (EKS) environments, where AWS-managed admission controllers may interfere with webhook evaluation order.

---

Changes

New Helm Value

A new optional value has been added under container.webhook:

# values.yaml
container:
  webhook:
    reinvocationPolicy: "Never"  # Allowed values: "Never" | "IfNeeded"

Template Update

templates/container_deployment_webhook.yaml now renders reinvocationPolicy dynamically:

reinvocationPolicy: {{ .Values.container.webhook.reinvocationPolicy | default "Never" }}

Documentation

• values.yaml — documents the new reinvocationPolicy field with its default value and accepted options.
• README.md — updated to reflect the new parameter under the container.webhook configuration table.
• Consolidated all webhook-related values under .Values.container.webhook for structural consistency.

---

Backward Compatibility

Concern	Status
Default reinvocationPolicy behavior	Unchanged (Never)
Existing values.yaml overrides	Fully compatible
Helm chart API version	No change
Breaking changes	None

---

Example Usage

To enable re-invocation when running alongside other mutating webhooks:

container:
  webhook:
    reinvocationPolicy: "IfNeeded"

---

Validation

• helm lint passes with both default and overridden values
• helm template renders the correct reinvocationPolicy field in the MutatingWebhookConfiguration
• Deployed and verified on EKS with reinvocationPolicy: Never (default) and IfNeeded (override)
• Confirmed Falcon sensor sidecar injection succeeds in the presence of Kyverno admission policies

---

References

• Kubernetes Docs — Reinvocation Policy
• Kyverno — Webhook Ordering

[EscobozaEstrada]

@mr-jungchoi please review this pr.