devops sitereliabilityengineering platformengineering
Core Idea
Policy as Code means your organizational rules, security constraints, and compliance requirements live as version-controlled, testable code instead of wiki pages and manual checklists.
- The core idea: rules you can diff, test, and review like software.
- Where policies get evaluated in the pipeline.
- The main tools in the Kubernetes space.
Introduction
Policy as Code (PaC) means writing your organizational rules, security constraints, and compliance requirements as version-controlled, testable code, instead of wiki pages, tribal knowledge, or manual review checklists.
Quote
Let’s say that the head of engineering has declared all deployed code must now have 90% or higher test coverage. In the old way of doing things, the DevOps team would code up a script or pipeline orb and add it to the standard development pipeline. But no DevOps team owns the pipelines in our new world of platform engineering. Instead, every development team owns its pipeline. And while our CTO trusts his development organization, he wants to keep everyone honest without taking control of their pipelines. We do this with our compliance at the point of change admission controllers.
The core idea
Traditionally, a policy like “no container should run as root” lived in a Word doc, a Confluence page, or a senior engineer’s head. It was enforced manually — during code review if you were lucky, or not at all. Policy as Code (PaC) takes that human intent and expresses it in a formal language that a machine can evaluate automatically and consistently.
The key properties it shares with good software:
- Version controlled — every change has an author, a timestamp, and a diff
- Testable — you write unit tests for policies just like you do for application code
- Reviewable — changes go through pull requests, not Slack approvals
- Automated — enforcement happens at every API call, not during quarterly audits
Where policies get evaluated
There are three natural checkpoints, and mature setups use all three:
Shift left (developer’s machine / CI) — tools like conftest or terraform validate let developers know about violations before they push. This is the cheapest place to catch problems; no cluster interaction needed.
SEPQM11.1 - Trends in Software Testing > Shift-Left Testing
Admission time (API server gate) — this is what the admission controller we built does. The policy runs synchronously when a resource is submitted. If it fails, the resource is never created. This is your enforcement safety net.
Continuous audit (in-cluster scanner) — OPA (Open Policy Agent) > OPA Gatekeeper and Kyverno can also scan resources that already exist. This catches drift: resources that were compliant when created but became non-compliant after a policy update, or resources that snuck in before the webhook was installed.
The main tools in the Kubernetes space
OPA (Open Policy Agent) is a general-purpose policy engine. You write policies in a declarative language called Rego. OPA is not Kubernetes-specific — the same engine enforces policy for Terraform, Envoy, Kafka, and HTTP APIs. In Kubernetes, OPA is typically deployed via Gatekeeper.
Gatekeeper wraps OPA with Kubernetes-native CRDs. You define a ConstraintTemplate (the policy logic in Rego) and then instantiate Constraint objects (apply that policy to specific resources). It acts as both a mutating and validating webhook.
Kyverno is an alternative that uses YAML instead of Rego. Policies are Kubernetes resources themselves. More approachable for teams not comfortable with a new query language; less expressive for very complex rules.
conftest is a CLI tool that applies OPA policies to structured data (YAML, JSON, HCL, Dockerfile) in CI — before anything reaches the cluster.