Traditional policy documents get ignored - Policy as Code doesn’t. By turning security and compliance rules into executable checks. No drift, no guesswork, no relying on people to remember rules.
Static policies - even the most well-written ones - are just text. They live outside your workflows and have no real enforcement. Someone might define “All S3 buckets must be private” in a policy doc, but who makes sure it stays that way? Usually no one - until an audit happens or a breach forces a cleanup.
The result? A reactive security posture where teams scramble to patch compliance gaps instead of preventing them.
That’s where Policy as Code (PaC) comes in. It bridges the gap between intent and enforcement by encoding your rules as executable, testable logic that lives alongside your code and infrastructure.
Policy as Code means expressing rules - like security controls, compliance standards, or architectural constraints - in a machine-readable format so they can be enforced automatically.
Instead of relying on documents and meetings, you define rules in policy files, version them in Git, test them in CI/CD, and enforce them at runtime.
Common use cases include:
At its core, PaC makes policies living, testable, and enforceable - not forgotten.
Open Policy Agent (OPA) is one of the most popular open-source engines for implementing Policy as Code. It’s a general-purpose policy decision engine that works across cloud, CI/CD, microservices, and Kubernetes.
You can deploy OPA in several ways:
OPA receives three things:
OPA then returns a decision - for example, “allow” or “deny” - based on the rules.
Rego is a declarative language designed for writing policies. Here’s a simple example:
1package policies.k8s23deny[msg] {4input.kind == "Pod"5not input.spec.containers[_].securityContext.runAsNonRoot6msg = sprintf("Pod %v must run as non-root", [input.metadata.name])7}
This policy blocks any Kubernetes Pod that doesn’t run as a non-root user.
Rego policies can define granular conditions, import external data (like allowed registries), and even include unit tests for validation - ensuring policies themselves are reliable and versioned like any other code.
You can embed OPA into your DevOps workflows easily:
For example, in a GitHub Actions pipeline:
1- name: Validate Infrastructure Policies2run: |3terraform plan -out=tfplan4terraform show -json tfplan > plan.json5opa eval --data policies/ --input plan.json "data.policies.deny"
If any deny rule triggers, the build fails automatically - preventing violations before deployment.
While OPA is general-purpose, Kyverno is purpose-built for Kubernetes and uses YAML instead of Rego. It’s designed to be developer-friendly and integrates directly into cluster operations.
You install Kyverno as a controller inside your cluster. It intercepts all resource creation and modification requests via the Kubernetes admission controller mechanism.
No need to write extra services - once deployed, Kyverno automatically validates or mutates Kubernetes manifests as they’re applied.
Kyverno policies are standard Kubernetes resources (Policy or ClusterPolicy). Here’s a simple one that blocks containers running as root:
1apiVersion: kyverno.io/v12kind: ClusterPolicy3metadata:4name: disallow-root-pods5spec:6validationFailureAction: enforce7rules:8- name: require-non-root9match:10resources:11kinds:12- Pod13validate:14message: "Containers must not run as root"15pattern:16spec:17containers:18- name: "*"19securityContext:20runAsNonRoot: true
You can also define mutate rules that automatically fix issues (for example, add missing labels or enforce encryption options).
Kyverno supports multiple enforcement levels:
Policies can also be applied GitOps-style - committed, versioned, and deployed via ArgoCD or Flux.
You don’t have to pick one. Many organizations use both:
Together, they ensure policies are enforced everywhere - from code to cloud. For example:
This layered approach ensures that no matter where the violation happens - design, build, or deploy - something catches it before production.
Policy as Code isn’t just about automation - it’s about reliability and trust. When policies are written as code, they can’t be ignored, forgotten, or “interpreted differently.” They enforce themselves. Tools like OPA and Kyverno make this practical and powerful. Instead of static PDFs, you get living rules that continuously protect your systems.
At Olymp Labs, we believe policies shouldn’t live in forgotten documents - they should live with your code.
