Should tenants own Kyverno Policy objects in their own namespaces on a shared cluster?

## The question behind the question "Can tenants write their own policies?" sounds like an RBAC question and is really an on-call question. The safety analysis is easy; the operations are not. ## Why delegation is safe: the model is additive Kyverno evaluates **every** matching rule from **every** installed policy for a given request. There is no precedence, no override, no allow rule that cancels a deny. A tenant's namespaced `Policy` therefore has exactly one power: it can add constraints to resources in its own namespace. Concretely, a tenant-owned `Policy` **cannot**: - relax, shadow or exempt anything in a platform `ClusterPolicy` that also matches their workloads; - reach resources in another namespace, however its match block is written; - match cluster-scoped kinds such as Namespace, ClusterRole or CustomResourceDefinition; - change the platform's exclusion list, or add itself to one. That is a genuinely rare property in platform delegation: the failure mode of a tenant writing a bad policy is that the *tenant* is worse off, not that the cluster's guardrails weaken. ## Why it is still not free: the costs land on the platform **The tenant can block themselves in ways they do not understand.** Kubernetes creates a lot of objects on a user's behalf, and a rule matching a kind that a tenant's own controller or operator creates will reject those creations with a message the tenant did not write. The result looks like a broken cluster, and the first page goes to the platform team. **Admission cost is shared.** More installed rules means more work per request, and the engine sits in the request path for everyone. A tenant with a broadly matched rule is spending a budget the platform owns. **Report volume is shared.** A tenant rule running in Audit produces findings in that namespace's report, but the reporting pipeline, the storage and the dashboards belong to the platform. **Debuggability.** When someone says "my Deployment was rejected", the platform engineer now has to consider both platform policies and any tenant-authored ones. The denial message is the thing that saves you: it should name the policy and rule so the responder can tell instantly whose rule fired. ## The shape of a delegation that works **Grant the narrow verb.** `create`, `update` and `delete` on `Policy` in the tenant's own namespace. Never `ClusterPolicy` — that verb lets a tenant write a rule that blocks the whole cluster, which is the one thing the additive model does not protect you from. **Route it through review.** The Policy object arrives via the tenant's existing GitOps repository like any other manifest, so it is reviewed, versioned and revertable. A tenant policy applied by hand is a change nobody can reconstruct at 2am. **Publish the contract.** Say plainly which guardrails the platform owns and will not remove, that tenant rules are additive only, and — the important half — that a rejection caused by a tenant's own policy is the tenant's incident. Without that line written down in advance, every rejection is the platform's problem by default. **Keep a break-glass.** The platform must be able to disable a tenant's policy object that is causing an outage, and must be able to say afterwards exactly what was disabled, when and by whom. This is about the *tenant's own* rule, not about waiving a platform guardrail. **Give them a starting point.** Most tenants do not want to author policy; they want one or two local rules. A small library of reviewed rule shapes — for example the availability guardrail requiring a readiness probe on multi-replica Deployments — that a team can copy into their namespace and narrow gets you most of the value with a fraction of the novel YAML. ## When to say no Delegation stops making sense when the tenant is not the operator: if the team has no on-call rotation and no ability to debug an admission rejection, handing them a mechanism whose failure mode is "nothing can be deployed" is not empowerment. In that case the better answer is that the platform authors the rule on the tenant's behalf, scoped to their namespace, and owns it — which costs the platform a small amount of work and saves it an unbounded amount of paging. ## What a strong answer sounds like It separates the two risks explicitly. The *authorization* risk is low and provably so, because of the additive evaluation model and the namespace boundary on the object. The *operational* risk is real and is paid by whoever answers the page. The decision is therefore not about trust; it is about whether the tenant can operate what they are being handed, and about writing down who is paged when it misfires.