Kyverno

Split 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.

Only that workloads admitted after the rule went live met the condition at that moment. It says nothing about pods admitted earlier, whether attestations are still fresh, or images no pattern selected.

Combine namespaces, kinds and a label selector in the exception's match block, and list the exact rule names. Avoid matching on pod names, which carry generated suffixes, and avoid a namespace-only match, which silently covers every future workload there.

A Kyverno ClusterCleanupPolicy matches a kind, narrows it with conditions such as a succeeded status, and carries a cron schedule; the cleanup controller deletes every match on each tick. A cleanup.kyverno.io/ttl label instead expires one specific object.

Two rules matched the same object: the rule Kyverno derived from a Pod rule for Deployments, and a separately maintained rule that matches Deployment directly. Kyverno reports every failing rule, so the same control is stated twice.

Put the three attestors as entries in one attestors set and give that set count: 2. Inside a set, count is a threshold over entries; omitting it requires all of them. Separate sets are ANDed.

Read the object's policies.kyverno.io/last-applied-patches annotation, which records the patch and the policy and rule that applied it. Corroborate with events on the resource, the policy report entry, and a Kyverno CLI replay of the policy.

Treat the count as a symptom, not a work queue. Break it down by rule and by owning team, delete or narrow rules nobody will ever act on, and tie what remains to a dated, per-team list.

Choose on reviewability, not expressiveness. Make the declarative pattern the default because governed teams can read it, allow deny conditions where operators or request fields are genuinely needed, and reserve the CEL form for teams already fluent in it.

Update rights on that ConfigMap are equivalent to amending the policy, so govern it like policy: platform-owned namespace, the same repository and review as the rule, alerting on writes, and a pre-agreed emergency path that is reconciled back into git.

Usually yes, with limits. A namespaced Kyverno Policy can only add constraints inside its own namespace and cannot relax a platform ClusterPolicy, so the security downside is small. The real cost is operational: tenants can block themselves.