Resource Selection: KCA practice questions

Every Kyverno rule starts by deciding which requests it applies to. The match block selects resources and an optional exclude block removes a subset of them, and both share one structure. Each contains either any or all, never both: any is a logical OR across its entries and all is a logical AND. Putting filters directly under match or exclude without any or all is deprecated.

Each entry is a resource filter, or a filter on who made the request. Under resources, kinds is mandatory, and the other fields narrow it: names and namespaces, both accepting wildcards; selector with matchLabels or matchExpressions on the resource's own labels; namespaceSelector on the labels of the resource's namespace; operations such as CREATE, UPDATE, DELETE or CONNECT; and annotations. If operations is left out, CREATE and UPDATE are matched. Inside one resources block the documentation describes the logic as AND across field types and OR within list types, so kinds: [Pod, Service] together with a selector means a Pod or a Service that also carries those labels. The subjects, roles and clusterRoles filters select users, groups and service accounts, namespaced Roles and ClusterRoles; conditions within them are ORed, and because that information only exists in an admission request, rules using them need background: false.

Kinds can be written as Kind, Version/Kind or Group/Version/Kind. The full form resolves conflicts when two API groups define the same kind, NetworkPolicy being the documented example. Wildcards work in kinds too, such as */Kind or a bare *, but policies matching all kinds cannot contain generate or verifyImages rules, and matching everything sends far more requests through Kyverno. Subresources are written with a slash or a dot, as in Pods/status, and the parent should be named explicitly because a subresource such as Scale is shared by several kinds.

Exclude must describe a subset of what match selects, and all match and exclude conditions have to hold for a resource to be selected.

Some selection cannot be expressed with match and exclude. Variables cannot be used there at all. When the decision depends on the content of the request, preconditions come next: they run after a resource has been matched and not excluded, combine expressions under any and all with operators such as Equals, NotEquals, AnyIn, AllNotIn, GreaterThan and the duration comparisons, and when they evaluate to false the rule is not applied and the result is recorded as skip. That differs from exclude, where the resource is ignored immediately.

Selection also happens before Kyverno sees a request. Its webhook only receives the kinds that installed policies match, its ConfigMap's resourceFilters skip some kinds such as Events by default, and the webhook namespaceSelector excludes the kube-system and kyverno namespaces unless reconfigured. A rule that seems not to fire may simply never receive the request.