> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Failure Action Overrides
> Explains Kyverno's failureActionOverrides for ClusterPolicies, allowing namespace specific enforcement or audit of validation rules to avoid duplicating policies.
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.
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`:
```yaml theme={null}
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.
* 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:
```yaml theme={null}
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/](https://kyverno.io/docs/writing-policies/validate/)
* Kubernetes admission control concepts: [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
That's it for this lesson.