ClusterPolicy on Kyverno

Policy Settings

Mon, 01 Jan 0001 00:00:00 +0000

A policy contains one or more rules, and the following common settings which apply to all rules in the policy:

admission: determines whether rules in this policy should be applied during admission control. This is an optional field with a default of true. If set to false then policies should be applied in background mode only (see further below).
applyRules: states how many of the rules in the parent policy should be applied to a matching resource. Values are One and All (default). If set to One, the first matching rule to be applied will stop further rules from being evaluated.

Selecting Resources

Mon, 01 Jan 0001 00:00:00 +0000

The match and exclude filters control the scope to which rules are applied. They have the same structure and can each contain only one of the two elements:

any: specify resource filters on which Kyverno will perform the logical OR operation while choosing resources
all: specify resource filters on which Kyverno will perform the logical AND operation while choosing resources

Resource Filters

The following resource filters can be specified under an any or all clause.

Validate Rules

Mon, 01 Jan 0001 00:00:00 +0000

Validation rules are probably the most common and practical types of rules you will be working with, and the main use case for admission controllers such as Kyverno. In a typical validation rule, one defines the mandatory properties with which a given resource should be created. When a new resource is created by a user or process, the properties of that resource are checked by Kyverno against the validate rule. If those properties are validated, meaning there is agreement, the resource is allowed to be created. If those properties are different, the creation is blocked. The behavior of how Kyverno responds to a failed validation check is determined by the failureAction field. It can either be blocked (Enforce) or allowed yet recorded in a policy report (Audit). Validation rules in Audit mode can also be used to get a report on matching resources which violate the rule(s), both upon initial creation and when Kyverno initiates periodic scans of Kubernetes resources. Resources in violation of an existing rule placed in Audit mode will also surface in an event on the resource in question.

Mutate Rules

Mon, 01 Jan 0001 00:00:00 +0000

A mutate rule can be used to modify matching resources and is written as either a RFC 6902 JSON Patch or a strategic merge patch.

By using a patch in the JSONPatch - RFC 6902 format, you can make precise changes to the resource being created. A strategic merge patch is useful for controlling merge behaviors on elements with lists. Regardless of the method, a mutate rule is used when an object needs to be modified in a given way.

Generate Rules

Mon, 01 Jan 0001 00:00:00 +0000

A generate rule can be used to create new Kubernetes resources in response to some other event including things like resource creation, update, or delete, or even by creating or updating a policy itself. This is useful to create supporting resources, such as new RoleBindings or NetworkPolicies for a Namespace or perform other automation tasks that may either require other tools or be scripted.

Some common use cases for generate rules include:

Variables

Mon, 01 Jan 0001 00:00:00 +0000

Variables make policies smarter and reusable by enabling references to data in the policy definition, the admission review request, and external data sources like ConfigMaps, the Kubernetes API Server, OCI image registries, and even external service calls.

In Kyverno, for a plain JMESPath variable, no double curly brackets are needed but for nested variables you need to use the double braces syntax.

For example:

- name: mountpath
 variable:
 jmesPath: request.object.metadata.annotations.optional || '/custom/string/{{request.object.metadata.annotations.mandatory"}}'

Here, no double curly brackets are needed in request.object.metadata.annotations.optional but for nested variables like /custom/string/{{request.object.metadata.annotations.mandatory"}}, you need wrap variable with {{}}. For variables in policy declarations the $( ... ) syntax is used instead.

External Data Sources

Mon, 01 Jan 0001 00:00:00 +0000

The Variables section discusses how variables can help create smarter and reusable policy definitions and introduced the concept of a rule context that stores all variables.

This section provides details on using ConfigMaps, API calls, service calls, and image registries to reference external data as variables in policies.

Variables from ConfigMaps

A ConfigMap resource in Kubernetes is commonly used as a source of configuration details which can be consumed by applications. This data can be written in multiple formats, stored in a Namespace, and accessed easily. Kyverno supports using a ConfigMap as a data source for variables. When a policy referencing a ConfigMap resource is evaluated, the ConfigMap data is checked at that time ensuring that references to the ConfigMap are always dynamic. Should the ConfigMap be updated, subsequent policy lookups will pick up the latest data at that point.

Auto-Gen Rules

Mon, 01 Jan 0001 00:00:00 +0000

Pods are one of the most common object types in Kubernetes and as such are the focus of most types of validation rules. But creation of Pods directly is almost never done as it is considered an anti-pattern. Instead, Kubernetes has many higher-level controllers that directly or indirectly manage Pods, namely the Deployment, DaemonSet, StatefulSet, Job, and CronJob resources. Third-party custom resources may also “wrap” or leverage the Pod template as part of their resources as well. Writing policy that targets Pods but must be written for every one of these controllers would be tedious and inefficient. Kyverno solves this issue by supporting automatic generation of policy rules for higher-level controllers from a rule written exclusively for a Pod. For rules which match on Pods in addition to other kinds, auto-generation is not activated.

Preconditions

Mon, 01 Jan 0001 00:00:00 +0000

Preconditions allow for more fine-grained selection of resources than the options allowed by match and exclude statements. Preconditions consist of one or more expressions which are evaluated after a resource has been successfully matched (and not excluded) by a rule. They are powerful in that they allow you access to variables, JMESPath filters, operators, and other constructs which can be used to precisely select when a rule should be evaluated. When preconditions are evaluated to an overall TRUE result, processing of the rule body begins.

JMESPath

Mon, 01 Jan 0001 00:00:00 +0000

JMESPath (pronounced “James path”) is a JSON query language created by James Saryerwinnie and is the language that Kyverno supports to perform more complex selections of fields and values and also manipulation thereof by using one or more filters. If you’re familiar with kubectl and Kubernetes already, this might ring a bell in that it’s similar to JSONPath. JMESPath can be used almost anywhere in Kyverno although is an optional component depending on the type and complexity of a Kyverno policy or rule that is being written. While many policies can be written with simple overlay patterns, others require more detailed selection and transformation. The latter is where JMESPath is useful.

Tips & Tricks

Mon, 01 Jan 0001 00:00:00 +0000

These are some tips and tricks you can use when putting together your Kyverno policies.

General

Need more examples or struggling to see a practical use case? Remember to check out the extensive community samples library for ideas on how to author certain types, as well as to kickstart your own needs. Very often, you may not need to start from scratch but can instead use one of the samples as a starting point to further customize.