When do you split Kyverno rules across separate policies instead of one ClusterPolicy?
answer
- object versus rule: which one is which
- behaviour per rule, lifecycle per object
- action is already a per-rule field
- what one delete takes with it
- would you ever revert one alone
basics
~20 sSplit when rules have different owners, review paths or lifecycles, because the policy object is the unit of creation, deletion and RBAC. Do not split merely to give rules different failure actions — that is already per-rule.
solid answer
~50 sA Kyverno policy holds a list of rules, and the object — not the rule — is the unit of lifecycle: one file in Git, one RBAC subject, one thing you delete. So split when the rules differ in *ownership or lifecycle*: a rule the security team reviews versus one the platform team owns; a brand-new rule you may need to pull without touching stable guardrails; a rule that only applies in one namespace and belongs in a namespaced Policy. Keep rules together when they express one coherent guarantee — the readiness probe and the PodDisruptionBudget reference for the same multi-replica availability contract — so they move, get reviewed and get reverted as a unit. What is *not* a reason to split is wanting different behaviour per rule: match, exclude and the failure action are all per-rule fields already.
go deeper
Know that a Kyverno policy holds a list of rules and that each rule has its own match block and message. You are not expected to design the grouping yet, only to read a multi-rule policy correctly.
Explain what is per rule and what is per object: match, exclude, message and failure action are per rule, while the name, the RBAC on it and its deletion are per object. That distinction drives every grouping decision.
Demonstrate the operational reasoning — blast radius on deletion, independent revert of a new rule, report readability, and reaching for a per-rule action change instead of deleting a policy during an incident.
Own the policy layout as an ownership map. Argue how policy objects line up with review paths and on-call responsibility, and resist a single mega-policy that makes every guardrail on the cluster one team's approval bottleneck.
## The object is the unit of lifecycle, the rule is the unit of behaviour A Kyverno `ClusterPolicy` or `Policy` carries a list under `spec.rules`, and every rule in that list is independently configured: its own `match`, its own `exclude`, its own message, and its own failure action. What the rules **share** is the object itself — one name, one YAML file in the GitOps repo, one set of RBAC subjects who can edit it, one `kubectl delete` that takes all of them away at once. That asymmetry is the whole answer. **Behaviour is per rule; lifecycle is per object.** Split when the *lifecycle* differs, not when the behaviour does. ## What is not a reason to split Candidates most often say "I split them so one can block and the other can only report." That is unnecessary: the action sits on the validate rule itself (`validate.failureAction`, set to `Enforce` or `Audit`), with the older policy-wide `spec.validationFailureAction` covering rules that do not set their own. So a single object can legitimately hold: - rule **require-readiness-probe** on `Enforce` — a multi-replica Deployment without a readiness probe is rejected at admission with the rule's message; - rule **require-pdb-reference** on `Audit` — the same Deployment is admitted, and the failure is written to a `PolicyReport` in the resource's namespace. Both actions are live at the same instant, in the same object, for the same Deployment. This is a structural property of the schema, not a phase of a rollout. Likewise, different match blocks are not a reason to split — each rule selects independently, so one rule can cover Deployments cluster-wide while its neighbour covers only one namespace's StatefulSets. ## Real reasons to split **Different owners.** If the security team owns one guardrail and the platform team owns the other, one object means one CODEOWNERS entry, one approval path, and an argument every time either side wants to change their own rule. Two objects give each owner an independent file. **Different maturity.** A brand-new rule that has not yet met the full estate is a different risk than a guardrail that has held for a year. Keeping the new one in its own object means removing it is a delete of that object — no edit to the file that carries the stable rules, no chance of a bad merge dropping something else. **Different scope.** A rule that only makes sense for one team belongs in a namespaced `Policy` in that namespace, which is by definition a different object. **Blast radius on deletion.** This is the one that bites during an incident. If five rules live in one policy and someone deletes the object to stop one noisy rule at 2am, four unrelated guardrails go dark and nobody notices until the post-incident review. The safer lever is to change *that rule's* failure action or narrow *that rule's* exclude — but under pressure, people reach for `delete`, and a smaller object limits what that costs. **Report readability.** Policy report entries name the policy and the rule. A single mega-policy called `platform-standards` with fifteen rules gives every finding on the cluster the same policy name, which makes routing and dashboards worse. ## Real reasons to keep them together **One coherent guarantee.** The availability contract "a Deployment with more than one replica must declare a readiness probe *and* reference a PodDisruptionBudget" is one promise expressed as two rules. Splitting it means the two halves can drift, be reviewed separately, and end up with one enabled and one not — which is a half-guarantee nobody can describe. **Shared vocabulary.** Rules in one object tend to share message style and exclude lists, and reviewers see them side by side. **Object count.** Every policy is a reconciled object. Hundreds of single-rule policies is a real operational cost for no benefit when the rules genuinely move together. ## The rule of thumb Ask: *would I ever want to remove, revert or hand over one of these rules without touching the others?* If yes, it wants its own object. If the honest answer is that they were only grouped because they were written the same afternoon, that is not a grouping — that is a merge conflict waiting to happen.
- Does splitting a policy in two let you give the rules different failure actions?It does, but you never needed to split for that. The action is a per-rule field on the validate block, so one policy can carry a rule on Enforce and a rule on Audit at the same time. Splitting for that reason just multiplies objects without buying anything.
- One rule in a five-rule policy is throwing false positives at 2am. What is the safest lever?Change that rule — flip its failure action to Audit so it reports instead of blocking, or add the offending namespace or ServiceAccount to its exclude block. Deleting the policy object stops all five rules at once, and the four you did not intend to drop go dark silently.
- How does a mega-policy with fifteen rules hurt you once findings start appearing?Policy report entries identify the policy and the rule, so every finding on the cluster carries the same policy name. Routing by policy stops working, dashboards blur together, and the owner of any single finding is harder to identify — the rule name becomes the only signal.
saying these in an interview costs you the question
- Splits policies purely to get different failure actions
- Treats the rule, not the object, as the deletion unit
- Groups unrelated rules because they were written together
- Deletes a whole policy to silence one noisy rule
- Cannot say who owns or reviews a given policy object