nicholasjackson/opa-rego-language

Rego is the declarative policy language used by Open Policy Agent (OPA). This tile covers writing and testing Rego policies for Kubernetes admission control, Terraform and infrastructure-as-code plan validation, Docker container authorization, HTTP API authorization, RBAC and role-based access control, data filtering, metadata annotations with opa inspect, and OPA policy testing with opa test.

1.19x

Quality

Pending

Does it follow best practices?

Impact

99%

1.19x

Average score across 31 eval scenarios

Securityby

Pending

The risk profile of this skill

Overview

Eval results

Files

Infrastructure as Code Policy Validation with Rego

Name: nicholasjackson/opa-rego-language
Rating: 0.99 (1 reviews)
Author: nicholasjackson

This document provides comprehensive examples of using Rego for Infrastructure as Code (IaC) validation, covering Terraform plans, AWS CloudFormation templates, and general infrastructure security policies.

Overview

Infrastructure as Code validation with OPA enables:

Pre-deployment validation of infrastructure changes
Enforcement of security and compliance requirements
Cost control and blast radius management
Consistent naming and tagging standards
Least privilege access control

IMPORTANT: Testing IaC Policies

The examples below include entrypoint: true on deny and warn rules, which is correct for governance tooling (opa inspect -a, opa build) and direct OPA evaluation. If you are evaluating policies with Conftest, remove entrypoint: true from all deny, warn, and violation rules — Conftest queries rules by naming convention and does not use OPA's entrypoint mechanism. Adding entrypoint: true to Conftest rules changes their default scope to document, which may produce unexpected behavior in multi-file packages.

Do not assume you know the field structure of a Terraform resource. Provider schemas change across versions and vary between providers. Before writing a policy for a specific resource type, use the Terraform MCP server to look up the current resource documentation and confirm the exact attribute names and their types as they appear in the plan JSON (change.after). Use search_providers to find the provider, then get_provider_details to retrieve the resource schema. For example, to confirm the ingress block attributes for aws_security_group, call get_provider_details with the resource type name. If the Terraform MCP server is not available, do not guess field names — ask the user to provide a sample plan JSON or the resource documentation.

Never run terraform plan or terraform apply to test policies. Rego policies MUST be tested exclusively using opa test. Do NOT run terraform plan, terraform apply, or any Terraform commands to validate policy logic. Terraform operations are slow, require real infrastructure configuration, and do not provide the fine-grained test coverage that opa test offers. If you need to test a policy against a Terraform plan, create a mock plan JSON input in your _test.rego file and use the with keyword to inject it.

Test file structure — name the file policy_test.rego. Per the Regal file-missing-test-suffix rule, test files must use the _test.rego filename suffix (e.g. terraform_test.rego alongside terraform.rego). The package should end in _test (e.g. package terraform.analysis_test). Use with input as to inject mock Terraform plan JSON. Include both a passing case (compliant resource, deny is empty) and a failing case (non-compliant resource, deny contains a message):

# terraform_test.rego
package terraform.analysis_test

import rego.v1
import data.terraform.analysis  # import the policy package under test

# Passing case: compliant resource → deny must be empty
test_compliant_bucket_allowed if {
    count(analysis.deny) == 0 with input as {"resource_changes": [{
        "type": "aws_s3_bucket",
        "address": "aws_s3_bucket.good",
        "change": {
            "actions": ["create"],
            "after": {"bucket_prefix": "my-prefix"}
        }
    }]}
}

# Failing case: non-compliant resource → deny must contain a message
test_missing_prefix_denied if {
    count(analysis.deny) == 1 with input as {"resource_changes": [{
        "type": "aws_s3_bucket",
        "address": "aws_s3_bucket.bad",
        "change": {
            "actions": ["create"],
            "after": {}
        }
    }]}
}

Always check both create and update actions. When writing policies that validate resource configuration (e.g., encryption, tags, security settings), always check for both "create" and "update" actions. A resource that passes validation at creation time can later be modified to a non-compliant state. Use the pattern: some action in r.change.actions; action in {"create", "update"}. Only omit "update" when the policy is specifically about initial resource creation (e.g., naming conventions that cannot change after creation).

Do not check for delete actions unless the policy specifically prevents resource deletion. Most policies validate resource configuration (encryption, tags, security settings) which is irrelevant when a resource is being destroyed. Only include "delete" in the action check when the policy is intended to prevent a resource from being deleted (e.g., protecting critical infrastructure from accidental removal).

Handle both raw Terraform and HCP Terraform/Enterprise input structures. The plan JSON input differs depending on how OPA is invoked:

Raw Terraform (via terraform show -json tfplan.binary): The plan JSON is the entire input, so resource_changes is at input.resource_changes.
HCP Terraform / Terraform Enterprise: The plan is nested under input.plan, with additional run metadata at input.run. So resource_changes is at input.plan.resource_changes.

Always use object.get to normalize access so policies work in both contexts without modification:

# Works with both raw Terraform and HCP Terraform/Enterprise input
tfplan := object.get(input, "plan", input)

This should be the default pattern in all Terraform IaC policies. With this in place, tfplan.resource_changes resolves correctly regardless of the input source. Policy rules then use tfplan consistently:

deny contains msg if {
    some r in tfplan.resource_changes
    r.type == "aws_s3_bucket"
    some action in r.change.actions; action in {"create", "update"}
    not r.change.after.server_side_encryption_configuration
    msg := sprintf("S3 bucket %v does not have encryption enabled", [r.address])
}