In a Kyverno rule, how do the match and exclude blocks decide which resources it applies to?

## What the two blocks are for Every Kyverno rule answers two questions before it decides anything: *does this rule apply here?*, then *does the object satisfy it?* `match` and `exclude` answer the first. Getting them wrong is the most common cause of both false positives (a rule firing on objects you never meant) and silent gaps (a rule that never fires at all). ## Structure Both `match` and `exclude` take one of two list forms: - **`any`** — the block matches if **at least one** entry matches (a logical OR); - **`all`** — the block matches only if **every** entry matches (a logical AND). Each entry in the list is a filter that may carry: - **`resources`** — `kinds`, `names`, `namespaces`, a label `selector`, `annotations`, and `operations` (CREATE, UPDATE, DELETE, CONNECT). Wildcards are allowed in names and namespaces, so `team-*` selects a family of namespaces. - **`subjects`** — the identity making the request, as a Kubernetes subject: a User, Group or ServiceAccount. - **`roles`** / **`clusterRoles`** — the roles bound to that identity. Conditions **within a single entry are ANDed**. An entry listing `kinds: [Deployment]` and `namespaces: [team-a]` means *Deployments in team-a*, not *Deployments anywhere, or anything in team-a*. To express the OR you need two entries under `any`. ## Exclude subtracts, and it wins `exclude` is evaluated against the same object and the same requester. If both blocks match, the rule is skipped for that request. There is no ordering subtlety to reason about: exclude is not "applied first" or "applied last", it is a subtraction from whatever `match` selected. The practical shape almost every real policy takes is a **broad match plus a narrow exclude**. Take the availability guardrail — a Deployment with more than one replica must declare a readiness probe. You match `Deployment` everywhere, because the point is that it holds everywhere. Then you carve out: - system namespaces such as `kube-system`, whose objects you do not own and cannot fix; - one named controller ServiceAccount that legitimately creates Deployments the rule would otherwise reject. Writing that as a narrow match instead — listing the namespaces you *do* want — looks equivalent and is not: every namespace created after you wrote the policy silently escapes the guardrail. Broad match plus explicit exclude fails in the safe direction, and the exclude list doubles as a readable, reviewable record of every hole in the rule. ## Matching on who is asking `subjects`, `roles` and `clusterRoles` match on the identity in the admission request rather than on the object. This is how you exempt a controller: a platform migration job running as `system:serviceaccount:platform-system:platform-migrator` is excluded, while a human applying the same manifest is not. Two things follow, and interviewers probe both. First, **identity is admission-only information**. Kyverno's background scan re-evaluates existing objects, and there is no requester to inspect at that point — the object was created hours ago by someone the API server is no longer telling anyone about. A policy whose match or exclude uses `subjects`, `roles` or `clusterRoles` therefore has to declare `background: false`; Kyverno rejects the policy otherwise. The practical cost is that the rule no longer contributes results for pre-existing resources: it only guards new and updated ones. Second, **a subject exclusion is a standing bypass**. Anything acting as that identity skips the rule, not just the workflow you had in mind. Keep the excluded subject list short, name specific ServiceAccounts rather than broad groups, and prefer excluding a namespace you control over excluding an identity that can act anywhere. ## Failure modes worth naming - **Kind without group/version ambiguity.** If two API groups serve the same kind name, spell the kind out fully so the rule binds to the one you meant. - **Assuming `any` when you wrote `all`.** An `all` block with two entries that can never both be true matches nothing, and a rule that matches nothing looks exactly like a rule that passes. - **Forgetting `operations`.** A rule that should only guard creation will also fire on every update unless you say so, which turns unrelated edits to an old object into a blocked request. - **Excluding by namespace when you meant by identity, or the reverse.** Excluding `kube-system` does not exempt a controller that creates objects in tenant namespaces; excluding the controller's ServiceAccount does not exempt objects a human creates in `kube-system`.