Generate and Cleanup

## Where generate sits among Kyverno's rule types A Kyverno policy (`ClusterPolicy` cluster-wide, or the namespaced `Policy`) holds a list of rules. Every rule has a `match` block selecting the objects it applies to, and exactly one action: `validate`, `mutate`, `generate`, or `verifyImages`. `validate` decides whether the incoming object is allowed. `generate` does something categorically different: when a matching object appears, Kyverno creates *other* objects somewhere in the cluster. The vocabulary is worth learning precisely, because interviewers use it: - **Trigger** - the object the rule matched. Frequently a `Namespace`. - **Downstream** - the object or objects Kyverno creates as a result. ## The canonical platform use: supply, do not demand A multi-tenant cluster wants every namespace to have a default-deny NetworkPolicy, a ResourceQuota sized for the tier, and an image-pull Secret for the internal registry. There are two ways to get there. The demanding version is a `validate` rule: reject any namespace that arrives without those objects. That is unworkable - a Namespace request cannot carry a NetworkPolicy, so the tenant would have to create the namespace, then be blocked on everything else until they applied three more manifests they did not write. The supplying version is a `generate` rule. The tenant creates a namespace; a moment later the namespace already contains the default-deny NetworkPolicy and the quota. The tenant did nothing, learned nothing, and is nonetheless compliant. That inversion - the guardrail is handed to people rather than required from them - is the single point of this rule type, and it is what an interviewer is listening for. ## Two ways to say what to create The `generate` block names the target `apiVersion`, `kind`, `name`, and (for a namespaced kind) `namespace`, usually interpolated from the trigger with a variable such as `{{request.object.metadata.name}}`. The body is then one of: - **`data:`** - the object's spec written inline in the policy. Right for something you author and version alongside the rule, such as a default-deny NetworkPolicy with an empty `podSelector` and no ingress or egress rules. - **`clone:`** - a `namespace` and `name` pointing at a live object to copy. Right for something whose contents are managed elsewhere, such as a registry pull Secret held in a platform namespace. `cloneList` copies several matching objects at once. ## It is not part of the admission answer This catches people out. The admission webhook does not create the downstream inline. Kyverno records the intent and its background controller reconciles it, so generation is asynchronous: the namespace exists for a short window before the NetworkPolicy does. Consequences worth stating out loud in an interview: a test that reads the downstream immediately after creating the trigger will flake, and a workload that races into a brand-new namespace can briefly run before its guardrail lands. By default the rule fires on triggers created from now on. `generateExisting: true` makes Kyverno also process matching objects that were already there when the policy was installed. ## Which identity creates the object The downstream is created by Kyverno's background controller under its own ServiceAccount, not the requesting user's. That account only holds the rights an administrator granted it, typically by adding an aggregated ClusterRole, so a brand-new generate rule that targets a kind nobody granted simply produces nothing and reports a failure - the most common first-day symptom. It also means the rule is a privilege boundary. A tenant who may create a namespace, and nothing else, can cause a Secret to be materialised that they could not have created themselves. That is usually the intent, but it is why the clone source and the generated content deserve the same review as any privileged automation. ## Generate does not replace validate A generate rule creates the object; it does not defend it. Nothing in it stops a tenant from deleting the NetworkPolicy an hour later, unless you also turn on synchronization, and even then there is a reconcile window. Mature setups pair the two: `generate` so every namespace starts correct, and a `validate` rule so removing or weakening the object is rejected. ## How to answer Name the trigger and downstream, say inline `data` versus `clone` of a live source, say that it runs in the background under Kyverno's own identity rather than in the admission response, and land the framing: validate demands, generate supplies.