Failure Action Overrides

Kyverno policies operate in two primary modes: Audit and Enforce. In many clusters you’ll want a single ClusterPolicy to behave differently depending on the target namespace—for example, strict enforcement in production but only auditing elsewhere. The failureActionOverrides field enables exactly that by letting you override a rule’s default failureAction for specific namespaces.

Use failureActionOverrides to keep one ClusterPolicy that adapts per-namespace behavior instead of duplicating policies. This reduces policy sprawl and makes intent clearer.

What is failureActionOverrides?

It’s an optional block you add inside a rule’s validate section.
It creates namespace-specific exceptions to the rule’s default failureAction.
It is only supported for ClusterPolicy objects because those policies span multiple namespaces.

The image is a slide introducing "failureActionOverrides," explaining that it allows creating exceptions for "failureAction" in specific namespaces, available for "ClusterPolicies."

How it works

Define a default failureAction for the rule (commonly Audit or Enforce).
Use failureActionOverrides to list namespaces and the alternate action to apply there.
Kyverno evaluates the rule and, if the resource’s namespace matches an override entry, applies the override action instead of the default.

Example: require an app label, audit by default, but enforce in production:

rules:
  - name: check-label-app
    match:
      any:
        - resources:
            kinds:
              - Pod
    validate:
      failureAction: Audit
      failureActionOverrides:
        - action: Enforce   # Action to apply for these namespaces
          namespaces:       # List of affected namespaces
            - "production"
      message: "The label `app` is required."
      pattern:
        metadata:
          labels:
            app: "?*"

Behavior examples

Production namespace: When a Pod is created in production, Kyverno finds the matching failureActionOverrides entry. The effective action becomes Enforce. If the Pod lacks the app label, admission is blocked and the request fails.

The image explains the behavior of a pod creation in a 'production' namespace, emphasizing that requests are blocked if the label is missing, given the 'failureAction' is set to 'Enforce'.

Non-overridden namespaces (e.g., development): Kyverno applies the rule’s default failureAction (Audit in the example). A missing app label is recorded as a violation but the Pod is admitted.

Quick summary

Namespace type	Effective action	Result when `app` label is missing
`production` (in overrides)	`Enforce`	Admission is blocked
`development` (not in overrides)	`Audit`	Violation is logged, request allowed

Deprecated top-level syntax You may encounter an older, deprecated pattern where validation failure action overrides were defined at the policy spec level. Avoid this in new ClusterPolicies:

spec:
  validationFailureActionOverrides:   # <-- deprecated at top level
    namespaces:
      - production
    action: Enforce
  rules:
    ...

The top-level validationFailureActionOverrides is deprecated. Prefer placing failureActionOverrides inside each rule for finer-grained control and clearer intent.

Best practices

Prefer rule-scoped failureActionOverrides for precise, readable policies.
Use Audit as the default for safer rollouts, and enable Enforce only where needed (e.g., production).
Keep override lists minimal and documented so reviewers can quickly understand exceptions.

References

Kyverno policies and validation: https://kyverno.io/docs/writing-policies/validate/
Kubernetes admission control concepts: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

That’s it for this lesson.

Watch Video

Demo Failure Action

Patterns Wildcards