Blog post image for Policy-as-Code Governance with OPA/Rego - How Open Policy Agent enforces infrastructure standards automatically: writing policies in Rego, wiring them into Terraform and Kubernetes, and blocking non-compliant changes in CI/CD before they merge.

Devtips

Prev in DevOps & DevSecOpsGitHub Actions Secrets and Environment Variables: Handle Config the Right Way Next in DevOps & DevSecOpsSecuring CI/CD with IAM Roles

Policy-as-Code Governance with OPA/Rego

Mohammad Abu MattarPublished: 24 Feb 202603 Mins read04 Mins listen

Markdown for AI

Why policy-as-code matters

The governance problem

Managing infrastructure at scale gets complicated fast.

As your infrastructure grows, keeping it consistent and compliant gets harder. Manual reviews don’t scale past a few teams, and configuration drift arrives on its own. What you need is enforcement that runs on every change without a human in the loop.

Common infrastructure issues

Developers accidentally making resources publicly accessible
Missing required tags on cloud resources
Non-compliant security group configurations
Kubernetes deployments without resource limits
Terraform modules bypassing organizational standards

The problem: manual governance

Why manual reviews fail

Code review and post-deployment checks depend on a tired human noticing one line in a 400-line diff. Standards get missed, security rules get worked around, and the issue surfaces after the apply. Guardrails have to run before the deploy to be worth anything.

What it costs

Unenforced policy shows up on the invoice and in the incident review:

Security breaches from misconfigured resources
Compliance violations leading to audits and fines
Cost overruns from unoptimized infrastructure
Operational chaos from inconsistent deployments

The fix: Open Policy Agent (OPA)

What OPA is

Open Policy Agent is a policy engine that keeps policy logic out of your application and infrastructure code. You write rules in Rego, a declarative query language, and OPA evaluates them against structured input: Terraform plans, Kubernetes manifests, CI/CD configuration, or any other JSON you hand it.

What you get

Unified enforcement across Terraform, Kubernetes, and custom tools
Declarative policies that are easy to understand and maintain
Pre-deployment validation to catch issues before they reach production
Audit trails for compliance and governance requirements
Organization-wide standards enforced consistently

Getting started with OPA and Rego

Installing OPA

# macOS
brew install opa

# Linux
curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_x86_64
chmod +x opa
sudo mv opa /usr/local/bin/

A basic Rego policy

1
# Deny public S3 buckets
2
package s3
3

4
deny[msg] {
5
    input.resource_type == "aws_s3_bucket"
6
    input.acl == "public-read"
7
    msg := sprintf("S3 bucket %s cannot be public", [input.name])
8
}
9

10
deny[msg] {
11
    input.resource_type == "aws_s3_bucket"
12
    input.acl == "public-read-write"
13
    msg := sprintf("S3 bucket %s cannot be public", [input.name])
14
}

Integrating OPA with Terraform

Using Conftest for Terraform

# Install conftest
brew install conftest

# Validate Terraform plan
terraform plan -json | conftest test -

Policy example: enforce tags

1
package terraform
2

3
deny[msg] {
4
    resource := input.resource_changes[_]
5
    resource.type in ["aws_instance", "aws_rds_cluster"]
6
    not resource.change.after.tags.Environment
7
    msg := sprintf("Resource %s must have Environment tag", [resource.address])
8
}
9

10
deny[msg] {
11
    resource := input.resource_changes[_]
12
    resource.type in ["aws_instance", "aws_rds_cluster"]
13
    not resource.change.after.tags.CostCenter
14
    msg := sprintf("Resource %s must have CostCenter tag", [resource.address])
15
}

Enforcing policies in Kubernetes

Installing OPA Gatekeeper

# Deploy Gatekeeper to your cluster
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.14/deploy/gatekeeper.yaml

A Kubernetes ConstraintTemplate

1
apiVersion: constraints.gatekeeper.sh/v1beta1
2
kind: K8sRequiredResources
3
metadata:
4
  name: require-resource-limits
5
spec:
6
  match:
7
    kinds:
8
      - apiGroups: ['']
9
        kinds: ['Pod']
10
    excludedNamespaces: ['kube-system', 'gatekeeper-system']
11
---
12
apiVersion: templates.gatekeeper.sh/v1
13
kind: ConstraintTemplate
14
metadata:
15
  name: k8srequiredresources
16
spec:
17
  crd:
18
    spec:
19
      names:
20
        kind: K8sRequiredResources
21
  targets:
22
    - target: admission.k8s.gatekeeper.sh
23
      rego: |
24
        package k8srequiredresources
25

26
        violation[{"msg": msg}] {
27
            container := input.review.object.spec.containers[_]
28
            not container.resources.limits.cpu
29
            msg := sprintf("Container %s must have CPU limit", [container.name])
30
        }
31

32
        violation[{"msg": msg}] {
33
            container := input.review.object.spec.containers[_]
34
            not container.resources.limits.memory
35
            msg := sprintf("Container %s must have memory limit", [container.name])
36
        }

CI/CD pipeline integration

GitHub Actions example

1
name: Policy Validation
2

3
on: [pull_request]
4

5
jobs:
6
  policy-check:
7
    runs-on: ubuntu-latest
8
    steps:
9
      - uses: actions/checkout@v3
10

11
      - name: Install OPA
12
        run: |
13
          curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_x86_64
14
          chmod +x opa
15
          sudo mv opa /usr/local/bin/
16

17
      - name: Run Policy Tests
18
        run: |
19
          opa test policies/ -v
20

21
      - name: Validate Terraform
22
        if: hashFiles('*.tf') != ''
23
        run: |
24
          terraform init
25
          terraform plan -json | opa eval -d policies/ 'data.terraform.deny' -f pretty

Best practices

1. Start at the organization level

Define policies at the organization level, not project level. Make them discoverable and documented.

1
# Start with clear policy namespaces
2
package org_policies.infrastructure.aws.security
3
package org_policies.kubernetes.workload

2. Fail safely

Distinguish between hard denials and warnings:

1
package my_policies
2

3
deny[msg] {
4
    # Hard deny: completely block this
5
    input.security_critical_violation == true
6
    msg := "This violates critical security policy"
7
}
8

9
warn[msg] {
10
    # Warning: recommend but allow with approval
11
    input.non_standard_naming == true
12
    msg := "Consider following naming standards"
13
}

3. Test your policies

# Test policy logic before deployment
opa test policies/ -v

4. Keep policies in version control

Keep policies in the same repo as infrastructure code, with proper code review processes.

Monitoring and auditing

Log policy violations

Capture and log every policy decision for audit trails:

1
package audit
2

3
log_decision[decision] {
4
    decision := {
5
        "action": "denied",
6
        "reason": input.violation_reason,
7
        "timestamp": input.timestamp,
8
        "resource": input.resource_id
9
    }
10
}

A rollout timeline

Phase	Focus	Timeline
Phase 1	Basic security policies (public access, required tags)	Week 1-2
Phase 2	Terraform integration in CI/CD	Week 3-4
Phase 3	Kubernetes Gatekeeper deployment	Week 5-6
Phase 4	Full auditing and monitoring rollout	Week 7-8

Wrapping up

Policy-as-code moves the check from after the deploy to before it.

With OPA and Rego, the same rules apply across Terraform, Kubernetes and whatever else you can feed JSON. Start with the security policies you’d be embarrassed to explain in an incident review, get those passing, then widen the net. Rolling out fifty policies at once mostly teaches your team how to add exceptions.

Resources

Was this useful?

Policy-as-Code Governance with OPA/Rego