How do you share Rego helpers across Gatekeeper ConstraintTemplates?

## The mechanism Inside a ConstraintTemplate, `spec.targets[0]` holds the `rego` block. Alongside it, `libs` is a list of additional Rego modules. Gatekeeper requires each of those modules to declare a package under the `lib` namespace — `package lib.pods` — and the main policy pulls it in with `import data.lib.pods`, then calls into it normally. That is the entire sharing mechanism, and its shape matters more than its syntax. ## A template is one self-contained object A ConstraintTemplate is a Kubernetes resource. When the API server stores it, it stores exactly what you sent: policy text and library text, inline. There is nothing else in scope. Concretely: - there is **no file path or import path** to somewhere outside the object; - there is **no registry or dependency resolution** step that fetches a module version; - **one template cannot import another template's library**, even if both are applied to the same cluster; - there is **no vendoring directory**; the library either lives inside this object or it does not exist for this policy. So "sharing" is not sharing at runtime. Every template that uses the helper carries its own copy of the source. ## Which makes templates build output The practical pattern that falls out is: the helper lives once, in a repository, as an ordinary Rego file with its own unit tests. A render step reads it and injects it into the `libs` of every template that declares a dependency on it, producing the manifests you apply. Then: - changing the helper means **re-rendering and re-applying every template that uses it**, and your pipeline should do all of them together rather than leaving a partially-updated fleet; - nobody hand-edits an applied ConstraintTemplate, because the next render would silently overwrite it; - the thing you test before rollout is the **rendered template**, not just the helper in isolation — a helper that passes its own unit tests can still be spliced into a policy that does not do what you meant. Without that discipline, copies drift: two templates end up carrying two versions of the same helper, and the bug you fixed once is still live in half the fleet. That drift is the real risk this feature introduces, and it is what an interviewer is probing for. ## Why the pipeline's rule library does not just port over The tempting question is: we already have a Rego library for the checks our pipeline runs over manifests — can the template import that? Two separate reasons it is not that simple. The first is mechanical, and covered above: there is nowhere for the template to import *from*. Reuse means copying the source in at build time, not referencing it. The second is semantic, and it bites even after you copy the file in. The two callers do not agree on where the object is. A check that runs over a manifest treats the document as `input` and reaches straight into `input.spec.containers`. A Gatekeeper rule sees the object at `input.review.object`, with the Constraint's configuration alongside at `input.parameters`. A helper written against the first shape returns nothing useful under the second — and because a helper that finds nothing simply contributes nothing, the resulting policy is inert rather than broken, which is the worst way for it to fail. The fix is a discipline, not a tool: **shared helpers take the object as a parameter and never read `input` themselves.** `containers(obj)` ports between callers; `containers` that reads `input.spec.containers` is welded to one of them. Each caller then does its own one-line extraction — the manifest check passes `input`, the template passes `input.review.object` — and everything below that line is genuinely shared. ## What good looks like A mature Gatekeeper rule repository usually has: helper modules under `lib`, each with unit tests; templates as templates in the build-system sense, with the helper spliced in; a check in CI that every rendered template still blocks its known-bad fixture and admits its known-good one; and a single apply step for the whole set, so a helper change lands everywhere at once or nowhere.