Skip to main content
Alex built a solid Kyverno security policy, but now it blocks a critical debugging tool. What should we do?
  • Disable the policy? No — that opens a large security hole.
  • Make the policy extremely complex with many excludes? No — that’s hard to maintain.
Kyverno provides a better option: PolicyException resources. They let you grant a controlled, auditable “hall pass” for specific resources without changing core policies.
The image is discussing the question "Why Not Just Edit the Policy?" in the context of Kyverno, highlighting that Kyverno policies have features like match, exclude, and preconditions but questioning the need for a separate resource.
Why not just edit the policy?
  • Team boundaries: a central security team owns cluster policies. Application teams should not have to request edits for each exception. PolicyException lets app teams create exceptions in a controlled, auditable way without touching the core policy.
  • Simplicity: adding many exclude blocks to policies creates long, hard-to-read policies. Exceptions keep the policy logic simple and make temporary or emergency exceptions explicit.
The image outlines roles in teamwork: the Policy Team defines security policies, the App Team manages applications and exceptions, and a PolicyException role requests exceptions without altering core policies.
The image presents a visual guide titled "Clean and Simple," highlighting three points: avoiding complex policies, readability through simpler policies with exceptions, and suitability for temporary or emergency access.
Important prerequisite: PolicyExceptions are opt-in. Nothing will work unless you explicitly enable the feature on the Kyverno admission controller.
The image contains a warning message about policy exceptions being disabled by default, with instructions to configure the Kyverno admission controller before using them.
To enable PolicyExceptions, set two flags in the Kyverno admission controller deployment:
  • --enablePolicyException — enable the PolicyException feature (true).
  • --exceptionNamespace — which namespace(s) may contain PolicyException resources.
Kyverno requires a namespace to control who can create exceptions. You can set --exceptionNamespace to * to allow exceptions from any namespace, but that is only appropriate in less restrictive environments.
Enable the feature by adding --enablePolicyException=true and set --exceptionNamespace (or *) in the Kyverno admission controller flags. The namespace value controls where PolicyException resources may be created.
The image provides instructions on enabling PolicyException in Kyverno Admission Controller Deployment by setting two flags: --enablePolicyException and --exceptionNamespace. It highlights a key point about allowing resources in all namespaces.
Hands-on scenario Alex faces a ClusterPolicy that disallows Pods from sharing host namespaces (hostPID, hostIPC, hostNetwork). This is a typical security rule, but a developer needs to run a debugging tool that must inspect host namespaces; the policy blocks it.
The image describes a challenge where a ClusterPolicy blocks pods from using host network or process ID namespaces, affecting a tool that requires access to the host's IPC namespace.
Goal: create a PolicyException that allows the important-tool Deployment in the delta namespace to bypass the specific rule for debugging.
The image displays a goal description stating, "Create a PolicyException to allow only the important-tool Deployment in the delta namespace to bypass this rule."
The ClusterPolicy we’re up against (simplified):
Note: failureAction: Enforce means Kyverno will actively block any resource that violates the rule. That’s why the debugging tool cannot be created. PolicyException blueprint A PolicyException is explicit and answers three questions:
  1. Which policy and rule(s) to bypass? (exceptions block)
  2. Which resource(s) get the exception? (match block)
  3. (Optional) Under what extra conditions? (conditions block)
Annotated blueprint:
Key details
  • policyName targets the exact policy to bypass. For a namespaced policy use the format namespace/policy-name.
  • ruleNames must list the rule names from the policy (or ["*"] to bypass all rules).
  • match supports the same selectors as Kyverno policies: kinds, namespaces, names, labelSelector, etc.
  • conditions are optional extra checks evaluated against the admission request or object.
Putting the blueprint into practice Alex’s exception will live in the delta namespace (which must be allowed by --exceptionNamespace). Important: Kyverno autogenerates rules for controller resources when a rule targets Pods. If a ClusterPolicy validates Pods, Kyverno creates corresponding autogen-... rules for Deployments, StatefulSets, Jobs, etc. To exempt a Deployment and its Pods, you must exempt both the original rule and the autogen rule. Final PolicyException to solve Alex’s problem:
Why two rule names?
  • host-namespaces is the original ClusterPolicy rule applying to Pods.
  • autogen-host-namespaces is the automatically generated rule that applies to controller resources (Deployment, StatefulSet, Job, etc.). Exempting both ensures both the Deployment and the Pods it creates are covered.
Using wildcards and namespaced policies
  • For a namespaced policy, specify the policy name as namespace/policy-name, for example:
  • To bypass all rules in a policy, use:
Table: Common Kyverno admission controller flags for PolicyExceptions
Setting --exceptionNamespace=* allows PolicyExceptions from any namespace. Use this only in trusted or non-production environments — wildcard exceptions increase risk.
Table: PolicyException core fields Recap
  • PolicyExceptions decouple temporary or special-case exceptions from core ClusterPolicies, improving maintainability and team autonomy.
  • The feature is opt-in: enable it on the Kyverno admission controller with --enablePolicyException and restrict creation locations with --exceptionNamespace.
  • A PolicyException explicitly identifies the policy and rule(s) to bypass, the target resources, and optional conditions.
  • Remember to include autogen rule names when you need to exempt controller resources (Deployments, StatefulSets, Jobs) in addition to Pods.
The image outlines three key learning points about PolicyExceptions, including their role in decoupling exception logic from core policies, the need for container flags to enable the feature, and the specification of policy and resource bypass.
Further reading and references Now that you understand how PolicyExceptions work, you can create a controlled exception for Alex’s important-tool deployment without changing the central security policy.

Watch Video

Practice Lab