Opa on Backend Engineering Strategy Tools

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).

Resources

Kubernetes Policy

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

Kubernetes has three distinct policy enforcement mechanisms. They sit at the same point in the request lifecycle — the admission controller — but differ in language, capability, and operational complexity.

	Kyverno	Gatekeeper (OPA)	ValidatingAdmissionPolicy
Language	YAML/JMESPath	Rego	CEL
Native to K8s	No (CRD)	No (CRD)	Yes (built-in)
Validate	Yes	Yes	Yes
Mutate	Yes	Limited	Yes (1.32+)
Generate	Yes	No	No
Image verify	Yes	No	No
GA since	—	—	K8s 1.30
Good for	Full-featured, K8s-native feel	Rego-first teams, policy-as-data	Simple rules, no extra install

ValidatingAdmissionPolicy (VAP)

Added in Kubernetes 1.26, GA in 1.30. Policies are built into the API server — no admission controller to deploy or maintain. Policy is written in CEL (Common Expression Language), a simple expression language also used in Kubernetes’ x-kubernetes-validations CRD validation.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
 name: "require-run-as-non-root"
spec:
 failurePolicy: Fail
 matchConstraints:
 resourceRules:
 - apiGroups: ["apps"]
 apiVersions: ["v1"]
 operations: ["CREATE", "UPDATE"]
 resources: ["deployments"]
 validations:
 - expression: >
 object.spec.template.spec.securityContext.runAsNonRoot == true
 message: "Pods must run as non-root"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
 name: "require-run-as-non-root-binding"
spec:
 policyName: "require-run-as-non-root"
 validationActions: [Deny]
 matchResources:
 namespaceSelector:
 matchLabels:
 enforce-policy: "true"

The ValidatingAdmissionPolicyBinding scopes where a policy applies — cluster-wide, specific namespaces, or by label selector.

CEL basics

CEL expressions have access to object (the incoming resource), oldObject (for updates), request (metadata, user, etc.), and params (a referenced ConfigMap or CRD for parameterisation).

# Simple field check
object.spec.replicas <= 10

# Nested optional field (use ?. for optional traversal)
object.spec.template.spec.?securityContext.?runAsNonRoot == optional.of(true)

# List comprehension — all containers must have limits
object.spec.template.spec.containers.all(c,
 has(c.resources) && has(c.resources.limits)
)

# String operations
object.metadata.name.startsWith("prod-")

MutatingAdmissionPolicy

Added in Kubernetes 1.32 (alpha). Brings CEL-based mutation — set defaults, inject labels, patch fields — without Kyverno or a webhook. Still early; not production-ready yet.

Gatekeeper

OPA running as a Kubernetes admission controller. Policies are written in Rego and stored as ConstraintTemplate CRDs. The separation between template (the Rego logic) and constraint (the enforcement configuration + parameters) is the key design pattern.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
 name: k8srequiredlabels
spec:
 crd:
 spec:
 names:
 kind: K8sRequiredLabels
 validation:
 openAPIV3Schema:
 properties:
 labels:
 type: array
 items: {type: string}
 targets:
 - target: admission.k8s.gatekeeper.sh
 rego: |
 package k8srequiredlabels

 violation[{"msg": msg}] {
 provided := {label | input.review.object.metadata.labels[label]}
 required := {label | label := input.parameters.labels[_]}
 missing := required - provided
 count(missing) > 0
 msg := sprintf("missing required labels: %v", [missing])
 }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
 name: require-team-label
spec:
 match:
 kinds:
 - apiGroups: [""]
 kinds: ["Namespace"]
 parameters:
 labels: ["team", "environment"]

Gatekeeper also supports audit mode — it continuously evaluates existing resources against policies and surfaces violations without blocking. Useful for measuring compliance against policies you’re not yet ready to enforce.

Gatekeeper vs Kyverno

Kyverno is better if your team does not know Rego and wants policies that look like Kubernetes manifests. Gatekeeper is better if you are already invested in OPA/Rego and want a single policy language across K8s and non-K8s surfaces (via Conftest).

The K8s-native VAP is the right default for simple validation rules on new clusters — no extra install, but it does not cover mutation (until 1.32+), generation, or image verification.

Resources

Gatekeeper documentation
Gatekeeper library — ready-made ConstraintTemplates
ValidatingAdmissionPolicy docs
CEL in Kubernetes
Kyverno — separate note

OPA & Rego

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

OPA (Open Policy Agent) is a general-purpose policy engine. It takes structured input (JSON), evaluates it against a policy written in Rego, and returns a decision. It does not care what the input represents — Kubernetes resources, Terraform plans, HTTP requests, CI artifacts — anything you can express as JSON.

Rego is the query language OPA uses to express policy. It is declarative and logic-based (Datalog-inspired), which is a different mental model from imperative code. The learning curve is real but the payoff is policies that are testable, composable, and auditable.

Install

brew install opa

Or download a binary from github.com/open-policy-agent/opa/releases. No dependencies.

Standalone eval

The fastest way to learn Rego is the REPL and the eval command — no Kubernetes, no Conftest, just OPA and a policy file.

# Interactive REPL
opa run

# Eval a query against a policy file and input
opa eval \
 --data policy.rego \
 --input input.json \
 "data.mypackage.allow"

# Run tests
opa test ./policies/

# Run tests with coverage
opa test --coverage ./policies/

# Check syntax without evaluating
opa check policy.rego

REPL basics

> data # inspect all loaded data
> input # inspect current input
> x := {"a": 1}; x.a == 1 # inline assignment and check
> :help

Rego basics

A policy file is a package with rules. Rules are boolean expressions — they are true when all conditions in the body hold.

package mypackage

# default value when no rule fires
default allow := false

# allow if both conditions hold
allow if {
 input.user == "admin"
 input.action == "read"
}

Sets and comprehensions

package mypackage

# set of violations — empty set means compliant
violations contains msg if {
 input.containers[_].image == "latest"
 msg := "image tag must not be latest"
}

# all images
images := {img | img := input.containers[_].image}

Iteration

Rego iterates implicitly. input.containers[_] means “for any element in containers”. Use [i] if you need the index.

# any container missing a CPU limit is a violation
violations contains msg if {
 container := input.containers[_]
 not container.resources.limits.cpu
 msg := sprintf("container %v has no CPU limit", [container.name])
}

Testing

OPA has a built-in test runner. Test files are Rego files with rules prefixed test_.

package mypackage_test

import data.mypackage

test_allow_admin if {
 mypackage.allow with input as {"user": "admin", "action": "read"}
}

test_deny_non_admin if {
 not mypackage.allow with input as {"user": "bob", "action": "read"}
}

opa test ./
# PASS: 2/2

Input and data

OPA separates input (the thing being evaluated — changes per request) from data (context that does not change — lookup tables, allowlists, base policy).

# data is loaded with --data, can be JSON or Rego
opa eval --data policy.rego --data allowlist.json --input request.json "data.authz.allow"

OPA as a server

OPA can run as a sidecar or standalone HTTP server. POST JSON to /v1/data/<package>/<rule> to get a decision.

opa run --server --addr :8181 policy.rego

curl -X POST http://localhost:8181/v1/data/mypackage/allow \
 -H "Content-Type: application/json" \
 -d '{"input": {"user": "admin", "action": "read"}}'
# {"result": true}

This is how Gatekeeper and Conftest use OPA under the hood.

Rego playground

The Rego Playground is the fastest way to experiment without installing anything. Paste a policy and input, evaluate, iterate.

Resources

OPA documentation
Rego Playground
Rego cheat sheet
OPA GitHub
Styra Academy — free Rego courses (Styra built OPA)

Opa 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

Kubernetes Policy

ValidatingAdmissionPolicy (VAP)

CEL basics

MutatingAdmissionPolicy

Gatekeeper

Gatekeeper vs Kyverno

Resources

OPA & Rego

Install

Standalone eval

REPL basics

Rego basics

Sets and comprehensions

Iteration

Testing

Input and data

OPA as a server

Rego playground

Resources