A Gatekeeper constraint passes its gator suite but never fires on Deployments — how do you catch that offline?

## The failure being described A rule requires every Pod to declare a readiness probe. The `ConstraintTemplate` compiles, the `Constraint` matches `kinds: ["Pod"]`, the suite has an allow case and a deny case, and both pass. It ships. Weeks later someone notices that no deploy has ever been blocked, and that plenty of workloads have no readiness probe at all. The suite was honest about what it tested and dishonest about what that meant. Every fixture was a hand-written bare Pod. Nobody in the organisation applies a bare Pod; they apply Deployments, Jobs and CronJobs, and the container spec that violates the rule lives inside `spec.template.spec` of a workload controller, not at the top level of a Pod. What happens in a real cluster is worth being precise about, because it is the part candidates most often get backwards. A Pod-matching constraint does still see controller-created Pods: when the ReplicaSet controller creates the Pod, that creation goes through admission like any other request, and the Pod is rejected. But the developer's `kubectl apply` of the Deployment succeeded. They see a green apply and a Deployment that never becomes ready, with the rejection buried in the ReplicaSet's events. Enforcement of a sort happened; useful feedback did not. Either way, your suite never told you which of those two worlds you were in. ## What expansion does Gatekeeper's expansion feature lets the engine reason about the resource a workload controller *would* generate. You declare it with an `ExpansionTemplate` (`expansion.gatekeeper.sh/v1alpha1`), which says three things: - **`applyTo`** — the parent groups, versions and kinds it applies to, for example group `apps`, version `v1`, kind `Deployment`. - **`templateSource`** — the path within the parent where the child's template lives, typically `spec.template`. - **`generatedGVK`** — the group, version and kind of the resource that path produces, for example core `v1` `Pod`. `gator expand` takes your manifests plus that template and prints the generated resources — the Pod a given Deployment would create. That output alone is diagnostic: it shows you, field by field, the object your rule will actually be handed. More importantly, when an `ExpansionTemplate` is part of the input to `gator test` or `gator verify`, the generated resources are reviewed as well as the originals. So a case whose `object` is a Deployment can be asserted to produce a violation from a Pod-matching rule, entirely offline. ## How that changes the suite The fix is not to add cases; it is to change what the fixtures are made of. Replace hand-written bare Pods with the workload manifests your developers write — a Deployment, a CronJob — plus the `ExpansionTemplate` that tells the engine how each one renders. Then: - The deny case proves the rule fires on the manifest a human will actually submit. - The allow case proves a compliant Deployment is not flagged. - A CronJob case is worth keeping separately, because a CronJob nests its pod template one level deeper than a Deployment does, and a `templateSource` path that is right for one is wrong for the other. Run `gator expand` by hand the first time you write a rule for a new parent kind. Seeing the rendered child is how you find out that the path you guessed does not exist and that your rule has been evaluating an empty object. ## The general lesson A policy suite tests two things at once: whether the rule *decides* correctly, and whether it *matches* anything. Rule-level tests cover the first well and the second not at all, because you hand the rule an input shaped exactly the way you assumed. Matching bugs — a wrong kind, an unmatched group, a pod template you never looked at — only show up when the fixture is the real document a developer submits. That is why the highest-value fixtures for a constraint are the workload manifests your organisation actually deploys, and why expansion, which turns those manifests into the objects the rule will be handed, is the piece that makes the offline suite trustworthy. The outcome this prevents is the worst outcome available to a guardrail: not a rule that blocks the wrong thing, which someone will complain about within the hour, but a rule that blocks nothing, passes every test, appears on a compliance dashboard as enforced, and is discovered only when the thing it was supposed to prevent happens.