skip to content

In a Kyverno generate rule, what does synchronize: true actually guarantee?

level: middleimportance: should knowfreq 56%

answer

  1. One-shot creation versus ongoing management
  2. Drift gets corrected, not prevented
  3. Hand edits do not survive
  4. Source can be the rule or a live object
  5. Background reconcile, so eventual

basics

~20 s

Kyverno keeps the generated copy in step with its source: hand edits to the downstream are reverted and changes to the rule body or the cloned source propagate. With synchronize false, the object is created once and never touched again.

solid answer

~40 s

`synchronize: true` puts the downstream object under continuous reconciliation instead of creating it once. Three things follow. A tenant who edits the generated NetworkPolicy by hand sees the edit reverted, because Kyverno rewrites it back to the rule's `data` body or the current contents of the `clone` source. A change the platform team makes - editing the inline body, or rotating the cloned pull Secret - propagates to every copy without anyone touching the namespaces. And a deleted downstream is recreated. With `synchronize: false` the object is a one-off: it is created when the trigger appears and Kyverno never looks at it again, so tenants can adapt it and drift is permanent. The reconciliation runs in the background controller, so it is eventual, not instantaneous - expect a short window, not an atomic revert.

code

yaml · 17 lines
yaml
rules:
  - name: sync-pull-secret
    match:
      any:
        - resources:
            kinds:
              - Namespace
    generate:
      apiVersion: v1
      kind: Secret
      name: regcred
      namespace: "{{request.object.metadata.name}}"
      synchronize: true
      clone:
        namespace: platform-system
        name: regcred
...

go deeper

for a junior

Know that the setting exists and that with it on, a generated object edited by hand goes back to what the rule says. Be able to name one thing you would keep synchronized, such as a default-deny NetworkPolicy.

for a middle

Explain both directions of the sync: hand edits are reverted, and changes to the rule body or the cloned source propagate to every copy. Note that reconciliation is in the background, so it is eventual.

for a senior

Show you have handled the fallout: how a tenant gets a legitimate exception without turning synchronization off, and what auditing you do before enabling it across an estate that has been drifting.

for a principal

Own the decision of which objects the platform governs continuously and which it merely seeds, and the review discipline that follows from one policy edit rewriting an object in every namespace.

## What synchronization changes A Kyverno `generate` rule creates a downstream object from either an inline `data` body or a `clone` of a live source. `synchronize` decides whether that creation is a one-shot event or an ongoing relationship. **`synchronize: false`** - fire and forget. The downstream is created when the trigger appears and is then an ordinary object the namespace owner controls. Edits stick. Deletions stick. **`synchronize: true`** - the downstream is managed. Kyverno's background controller keeps it matching its definition, so: - a hand edit to the generated object is overwritten back to the source of truth; - a change to the policy's inline `data`, or to the cloned source object, propagates out to every copy; - a deleted downstream is recreated; - the downstream's lifecycle becomes coupled to the trigger and the policy, which is what makes deleting either of those consequential. ## Data versus clone, and why synchronization means something different for each With `data:`, the source of truth is the policy document itself. Synchronization means *the copies match the rule*. Change the rule, and a fleet of NetworkPolicies changes with it. This is genuinely powerful and genuinely dangerous: one edit to one ClusterPolicy rewrites an object in every namespace in the cluster, so the policy repository deserves the same review discipline as production code. With `clone:`, the source of truth is a live object in a platform namespace, typically an image-pull Secret. Synchronization means *the copies match that object*. Rotating the registry credential in one place refreshes every namespace's copy. The flip side is that the source object is now a cluster-wide dependency: whoever can write it can write into every tenant namespace. ## The support ticket this generates The classic platform-team experience: a tenant needs to allow one ingress path, edits the generated default-deny NetworkPolicy, watches it work for a few seconds, and then watches their change disappear. They file a bug against the network, not against the policy. This is the mechanism working exactly as designed, and it is also a real usability problem, so the answer an interviewer wants is not just *why* it reverted but *what you do about it*: - **Give the exception a supported shape.** Generate the baseline object under a fixed, obviously-owned name, and let tenants add their own additional NetworkPolicies alongside it, which the rule never touches. The guardrail stays reconciled; the tenant still has a way to allow traffic. - **Make ownership visible.** Labels and annotations on the generated object saying which policy owns it, plus documentation the error path points at, turn a mystery into a known rule. - **Do not reach for `synchronize: false` as the fix.** It stops the reverts by giving up the guarantee, and you will discover a year later that a third of your namespaces have quietly weakened their default-deny. ## Eventual, not atomic Reconciliation happens in the background controller, not inside the admission response for the tenant's edit. The edit is admitted, applied, and then reverted. Two things follow. First, there is a window in which the weakened object is live, so synchronization is a drift-correction mechanism and not an access control - if the edit must actually be refused, that is a `validate` rule on updates to the object. Second, a test that edits the downstream and immediately asserts it was restored will be flaky; the assertion needs to poll. ## Choosing between the two settings Use `synchronize: true` for anything that is a guardrail or a shared credential: default-deny NetworkPolicies, quotas, pull Secrets. The whole point is that they stay correct and stay current. Use `synchronize: false` for something you are seeding rather than governing - a starter ConfigMap, a sample resource, a default the team is explicitly expected to grow out of. If you cannot say which of those two categories an object is in, that is the design question to settle before writing the rule, because it is much harder to switch a fleet later: turning synchronization on across an existing estate will overwrite whatever tenants have quietly customised.

  • A tenant needs one ingress path allowed but the generated NetworkPolicy keeps reverting. What do you offer them?
    Not `synchronize: false`. Keep the generated baseline reconciled under a fixed name the rule owns, and let tenants create additional NetworkPolicies of their own alongside it, which the rule never touches - Kubernetes unions NetworkPolicies, so the allowance is additive. Label the generated object with the owning policy so the revert stops being a mystery.
  • Does synchronization stop a tenant from weakening the object?
    No. The edit is admitted and applied, then corrected by the background controller a moment later, so there is a real window where the weakened object is live. Synchronization is drift correction. If the change must actually be refused, add a validate rule that rejects updates and deletes against that object.
  • You are turning synchronization on for a rule that has been running with it off for a year. What is the risk?
    Every downstream copy is about to be rewritten to the rule's definition, discarding whatever tenants customised in the meantime - possibly including allowances their workloads depend on. Diff the live copies against the rendered definition first, enable it on a small set of namespaces, and tell owners before the fleet-wide flip.

saying these in an interview costs you the question

  • Says synchronize prevents the edit from being accepted
  • Thinks synchronization only applies to cloned sources
  • Assumes the revert is instantaneous and atomic
  • Reaches for synchronize false as the fix for tenant complaints
  • Does not realise editing the policy rewrites every copy

context

resolving links…