Reduced operational burden

Oct 13, 2025 by talynt.org 114 views

Why

Although Kyverno policies contain multiple methods to provide fine-grained control as to which resources they act upon, usually in the form of match/exclude blocks, preconditions at multiple hierarchies, anchors, and more, all these mechanisms have in common that the resources which they are intended to exclude must occur in the same rule definition. This may be limiting in situations where policies may not be directly editable, or doing so imposes an operational burden.

For example, in organizations where multiple teams must interact with the same cluster, a team responsible for policy authoring and administration may not be the same team responsible for submission of resources. In these cases, it can be advantageous to decouple the policy definition from certain exclusions. Additionally, there are often times where an organization or team must allow certain exceptions which would violate otherwise valid rules but on a one-time basis if the risks are known and acceptable.

What is the use case for the feature you are requesting? What are you trying to solve?

Imagine a validate policy exists in Enforce mode which mandates all Pods must not mount host namespaces. A separate team has a legitimate need to run a specific tool in this cluster for a limited time which violates this policy. Normally, the policy would block such a “bad” Pod if the policy was not previously altered in such a way to allow said Pod to run. Rather than making adjustments to the policy, an exception may be granted.

In this scenario, the team responsible for policy authoring and administration may not be aware of the specific tool that needs to be run, or they may not have the necessary permissions to make changes to the policy. This is where policy exception objects come in. By defining a policy exception object, the team responsible for submitting resources can request an exception to the policy, which can be reviewed and approved by the team responsible for policy authoring and administration.

Proposed Solution

To address this use case, we propose adding a new key called policyExceptions to the values file. This key will contain a list of policy exception objects, each with its own set of properties.

We also propose adding a new template called policyexceptions.yaml. This template will be used to generate the policy exception objects based on the values defined in the policyExceptions key.

Here is an example of what the policyexceptions.yaml template might look like:

{{- range $name, $values := .Values.policyExceptions }}
{{- if and $.Values.enabled $values.enabled }}
{{- if not (has $values.kind (list "PolicyException")) }}
{{- fail (printf "Invalid kind (%s) for policy named %s." $values.kind $name) }}
{{- end }}
---
apiVersion: kyverno.io/v2beta1
kind: {{ default $values.kind "PolicyException" }}
metadata:
  name: {{ $name }}
    {{- if $values.namespace  }}
  namespace: {{ $values.namespace }}
    {{- else }}
      {{- fail (printf "PolicyException named %s requires a namespace." $name) }}
    {{- end }}
  annotations: {{- toYaml (default dict $values.annotations) | nindent 4 }}
  labels: {{- include "kyverno-policies.labels" $ | nindent 4 }}
spec: {{- toYaml $values.spec | nindent 2 }}
{{- end }}
{{- end }}

This template uses the range function to iterate over the policyExceptions key in the values file. For each policy exception object, it generates a new policy exception resource based on the properties defined in the object.

Why is this approach recommended/better?

This approach is recommended because it allows for a more decoupled and flexible way of defining policy exceptions. By separating the policy definition from the policy exceptions, we can make it easier to manage and maintain policies, and reduce the operational burden associated with making changes to policies.

Additionally, this approach allows for a more granular and fine-grained control over policy exceptions. By defining policy exception objects, we can specify exactly which resources are exempt from the policy, and for how long.

Benefits

The benefits of this approach include:

Improved flexibility: By decoupling the policy definition from the policy exceptions, we can make it easier to manage and maintain policies.
Reduced operational burden: By reducing the number of changes that need to be made to policies, we can reduce the operational burden associated with making changes to policies.
Improved control: By defining policy exception objects, we can specify exactly which resources are exempt from the policy, and for how long.

Conclusion

Q: What is the purpose of policy exception objects?

A: Policy exception objects are used to exempt specific resources from a policy, allowing for a more flexible and fine-grained control over policy enforcement.

Q: How do policy exception objects differ from other policy mechanisms?

A: Policy exception objects differ from other policy mechanisms in that they allow for a more decoupled and flexible way of defining policy exceptions. Unlike other policy mechanisms, which require the policy definition to be modified to exempt specific resources, policy exception objects can be defined independently of the policy definition.

Q: What are the benefits of using policy exception objects?

A: The benefits of using policy exception objects include:

Improved flexibility: By decoupling the policy definition from the policy exceptions, we can make it easier to manage and maintain policies.
Reduced operational burden: By reducing the number of changes that need to be made to policies, we can reduce the operational burden associated with making changes to policies.
Improved control: By defining policy exception objects, we can specify exactly which resources are exempt from the policy, and for how long.

Q: How are policy exception objects defined?

A: Policy exception objects are defined using a new key called policyExceptions in the values file. This key contains a list of policy exception objects, each with its own set of properties.

Q: What properties are required for a policy exception object?

A: The following properties are required for a policy exception object:

name: The name of the policy exception object.
namespace: The namespace in which the policy exception object is defined.
kind: The kind of policy exception object (e.g. "PolicyException").
spec: The specification of the policy exception object.

Q: Can policy exception objects be used with existing policies?

A: Yes, policy exception objects can be used with existing policies. By defining a policy exception object, you can exempt specific resources from an existing policy, without modifying the policy definition.

Q: How are policy exception objects enforced?

A: Policy exception objects are enforced by the Kyverno policy engine. When a resource is created or updated, the Kyverno policy engine checks if the resource is exempt from the policy due to a policy exception object. If the resource is exempt, the Kyverno policy engine will not enforce the policy.

Q: Can policy exception objects be used to exempt multiple resources?

A: Yes, policy exception objects can be used to exempt multiple resources. By defining a policy exception object with a list of resources, you can exempt multiple resources from a policy, without modifying the policy definition.

Q: How do policy exception objects interact with other policy mechanisms?

A: Policy exception objects interact with other policy mechanisms by overriding the policy enforcement for specific resources. When a policy exception object is defined, it takes precedence over other policy mechanisms, and the Kyverno policy engine will not enforce the policy for the exempted resources.

Q: Can policy exception objects be used to exempt resources from multiple policies?

A: Yes, policy exception objects can be used to exempt resources from multiple policies. By defining a policy exception object with a list of policies, you can exempt resources from multiple policies, without modifying the policy definitions.

Q: How do policy exception objects improve policy management?

A: Policy exception objects improve policy management by providing a more flexible and fine-grained control over policy enforcement. By decoupling the policy definition from the policy exceptions, we can make it easier to manage and maintain policies, and reduce the operational burden associated with making changes to policies.