Policy as Code — Overview

Tue, 09 Jun 2026 00:00:00 +0000

Encoding compliance, security, and operational rules as version-controlled, testable code — evaluated at the point where things are created or changed rather than audited after the fact.

The alternative is manual review and reactive alerts. Policy as code shifts that left: rules are explicit, reviewable, and enforced automatically.

Enforcement points

The same policy intent can be applied at three different points in the lifecycle:

CI/CD gate — evaluate before anything reaches the cluster. Fail the pipeline on violations. Tools: Conftest, Checkov, Trivy IaC. Lowest blast radius, fastest feedback loop.

Cluster admission — intercept every kubectl apply at the API server. No non-compliant resource can be created or updated. Tools: Kyverno, Gatekeeper (OPA), K8s-native ValidatingAdmissionPolicy.

Runtime / drift detection — continuously evaluate live state against policy and surface violations. Catches things that predate the policy, or that arrived outside normal pipelines. Tools: OPA, AWS Config, Kyverno audit mode.

Most teams layer these: CI catches the obvious mistakes early and cheap, admission control enforces hard requirements at the cluster boundary, audit mode gives visibility into what is already out of compliance.

How the tools relate

OPA is the common engine underneath Gatekeeper and Conftest. Rego is its policy language — learn it once and it applies across both. Kyverno is a separate engine that replaces Rego with Kubernetes-native YAML; lower barrier to entry, but the policy language does not transfer outside K8s. The K8s-native ValidatingAdmissionPolicy uses CEL, a simpler expression language built into the API server — no extra install, but limited to validation and basic mutation.

Policy intent
 ├── CI/CD gate → Conftest (Rego) / Checkov / Trivy IaC
 ├── K8s admission → Kyverno (YAML) / Gatekeeper (Rego) / VAP (CEL)
 └── Runtime → OPA server / Kyverno audit / AWS Config

To explore

Rego standalone — eval policies against arbitrary JSON input using opa eval and the REPL, without Kubernetes. Good way to learn the language in isolation before wiring it into a pipeline or cluster. See the OPA & Rego note.

Conftest

Mon, 08 Jun 2026 00:00:00 +0000

Conftest is a CLI tool that runs OPA policies against structured config files — Kubernetes manifests, Terraform plans, Helm output, Dockerfiles, GitHub Actions workflows, anything that can be parsed. It is the CI/CD enforcement layer on top of Rego.

Write a policy once in Rego, run conftest test in your pipeline, fail the build if violations are found.

Install

brew install conftest

Basic usage

# Test a Kubernetes manifest
conftest test deployment.yaml

# Test all YAML in a directory
conftest test k8s/

# Test a Terraform plan (JSON output)
terraform show -json tfplan > tfplan.json
conftest test tfplan.json --parser json

# Test Helm-rendered output
helm template my-app ./chart | conftest test -

By default Conftest looks for policies in ./policy/. Change with --policy.

Policy structure

Policies are Rego files in the policy/ directory. Conftest checks for deny, warn, and violation rules.

# policy/k8s.rego
package main

# deny blocks the pipeline
deny contains msg if {
 input.kind == "Deployment"
 not input.spec.template.spec.securityContext.runAsNonRoot
 msg := sprintf("Deployment %v must set runAsNonRoot", [input.metadata.name])
}

# warn prints a warning but does not fail
warn contains msg if {
 input.kind == "Deployment"
 not input.metadata.labels["app.kubernetes.io/version"]
 msg := sprintf("Deployment %v is missing version label", [input.metadata.name])
}

$ conftest test deployment.yaml
FAIL - deployment.yaml - main - Deployment nginx must set runAsNonRoot
WARN - deployment.yaml - main - Deployment nginx is missing version label

2 tests, 0 passed, 1 warning, 1 failure

Namespaces

Use --namespace to scope which Rego package Conftest evaluates. Useful when you have per-resource-type policies in separate packages.

conftest test deployment.yaml --namespace kubernetes.deployments

Multiple parsers

Conftest supports many input formats. Common ones:

Flag	Parses
`--parser yaml`	YAML (default for `.yaml`/`.yml`)
`--parser json`	JSON, Terraform plan
`--parser hcl2`	Terraform HCL
`--parser dockerfile`	Dockerfiles
`--parser toml`	TOML

Policies can be distributed as OCI artifacts and pulled with conftest pull.

conftest pull ghcr.io/myorg/policies:latest
conftest test deployment.yaml

The Conftest policy hub documents the format. Useful for sharing a common policy library across repos without copy-pasting Rego.

In CI

# GitHub Actions example
- name: Policy check
 run: |
 conftest test k8s/ --policy policy/

Exits non-zero on deny violations. warn violations print but do not fail the build — useful for phased enforcement (warn first, deny later).

Conftest on Backend Engineering Strategy Tools

Policy as Code — Overview

Enforcement points

How the tools relate

To explore

Conftest

Install

Basic usage

Policy structure

Namespaces

Multiple parsers

In CI

Resources

Conftest on Backend Engineering Strategy Tools

Policy as Code — Overview

Enforcement points

How the tools relate

To explore

Conftest

Install

Basic usage

Policy structure

Namespaces

Multiple parsers

Sharing policies

In CI

Resources