What does a Gatekeeper Assign resource do, and how does it differ from a Constraint?

## Two different jobs Gatekeeper ships two families of cluster objects. Constraints **validate**: they run a Rego `violation` rule supplied by a ConstraintTemplate and their answer is allow or deny. Mutators **repair**: they patch the object on its way through admission and have no way to say no. Both are ordinary Kubernetes resources you apply with `kubectl` and ship through the same GitOps flow, which is the whole point of Gatekeeper's design — the rule is a cluster object, not a binary you deploy. ## The mutation CRDs | Resource | What it writes | |---|---| | `Assign` | any non-metadata field, set to a literal value | | `AssignMetadata` | a label or annotation — and only one that is not already present | | `ModifySet` | members of a list treated as a set, `merge` to add or `prune` to remove | | `AssignImage` | the domain, path and tag components of an image reference | The restriction on `Assign` is worth memorising: it is not allowed to write into `metadata`. That is exactly why `AssignMetadata` exists, and `AssignMetadata` is deliberately weak — it may **add** a label or annotation, never overwrite an existing value. A rule that stamps `owner: platform` on every namespaced object will leave a team's own `owner` value alone. ## Anatomy of an Assign - **`applyTo`** — a list of `{groups, versions, kinds}`. Core objects such as Pod use `groups: [""]`, the empty string, not `"core"` and not `"v1"`. - **`match`** — which of those objects, by `namespaces`, `excludedNamespaces`, `labelSelector`, `namespaceSelector`, `name` and `scope`. Both `applyTo` and `match` must be satisfied. - **`location`** — a dotted path from the object root to the field, with list entries selected by a key filter such as `spec.containers[name:*]`. - **`parameters.assign.value`** — the value to write. `parameters.pathTests` can require a subpath to exist or not exist before the write lands. A typical first rule sets `spec.automountServiceAccountToken` to `false` on Pods outside a few system namespaces: the workload never asked for a service-account token, and now it does not get one mounted, with no ticket filed against the owning team. ## What that buys, and what it costs The benefit is that nobody is blocked. A validating rule for the same field turns into a queue of pull requests across every team; the mutator just fixes it. The cost is that **there is no feedback channel at all**. A Constraint that denies produces an error message on the developer's terminal and, in `dryrun` mode, a violation recorded in the Constraint's own status. A mutator that fires produces nothing, and — more importantly — a mutator that matches nothing also produces nothing. Silence is both the success signal and the failure signal, so you have to verify separately that the field really is set on the objects you care about. Mutation also applies only to requests going through admission — creates and updates. Objects already sitting in etcd when you install the mutator were admitted before it existed and are untouched by it. ## The common wrong answers Candidates often say a mutator can "deny if it can't fix". It cannot; the two behaviours live in different resources, and if you want a hard stop you write a Constraint as well. Others reach for Rego, assuming every Gatekeeper rule is Rego — the mutation CRDs are pure structured YAML with no policy language in them, which is a large part of why teams adopt them first. And several will try to set a label with `Assign`, which is rejected: metadata belongs to `AssignMetadata`.