Policy as code expresses governance, security, and compliance requirements as machine-readable rules that a platform can evaluate when an action occurs. An enforcement gate at the point of change lets teams retain control of their development pipelines while the platform checks shared requirements. The alternative—putting compliance work inside centrally controlled pipelines—can make autonomy depend on who owns the delivery process. section 4.1.1 section 4.4
A deployment boundary is one place to start. A Kubernetes admission controller can check a proposed deployment before the API accepts it. For example, a Gatekeeper policy can require a labels object and can be refined to specify which labels are required. The check governs what reaches the environment, rather than prescribing how developers build or run their pipelines. section 4.1.1 section 4.4
Figure 4.4 Admission controller built using Gatekeeper (https://github.com/open-policy-agent/gatekeeper), which checks for labels on the deployment
The Gatekeeper admission-controller example makes a deployment-label requirement concrete. section 4.1.1
Choose the policy language with its wider use in mind. Gatekeeper builds on Open Policy Agent (OPA) and Rego, but its Kubernetes-resource-shaped policies differ from a general policy language. If multiple disciplines will share policy-as-code practices, those differences—and assumptions about distributing policies—may create friction later. Agreeing on a common standard early is easier than reconciling implementations after adoption. section 4.1.1 section 4.4
Place checks where the platform can act on a decision:
- At deployment, use an admission controller to verify requirements before a change is accepted. Outside Kubernetes, a Terraform-managed environment can use Sentinel, or a proxy can verify calls before forwarding them to a cloud API. section 4.1.1
- For service access, route calls through a service-mesh proxy to OPA. A policy can use request attributes, including a decoded web-token payload, to decide whether the caller may reach a service. Policies can be fetched remotely or cached and refreshed. section 4.3.2
- For supply-chain trust, pair policy checks with an auditable path from commit to deployment: signed commits, identified pipeline access, signed images, and a signed software bill of materials. Configure those controls at the relevant source-control, pipeline, and registry boundaries rather than relying on manual review. section 4.3.1
Not every check must block a change. A scan triggered immediately afterward can report and alert on violations. Start with a consequential boundary, decide whether it needs a precheck or postcheck, and keep compliance work separate from developer-owned orchestration. The aim is enforceable trust without making routine delivery depend on a central team's pipeline. section 4.1.1
