OPA vs Sentinel: Enterprise Policy as Code Comparison (2025)

Example: Deny EC2 instances without encryption

package terraform.analysis

import input as tfplan

# Find all EC2 instances in the plan
ec2_instances := [resource |
    resource := tfplan.resource_changes[_]
    resource.type == "aws_instance"
    resource.change.actions[_] == "create"
]

# Find instances without encryption
unencrypted_instances := [instance |
    instance := ec2_instances[_]
    not instance.change.after.root_block_device[_].encrypted
]

# Deny if any unencrypted instances exist
deny[msg] {
    count(unencrypted_instances) > 0
    msg := sprintf("Found %d EC2 instances without encryption", [count(unencrypted_instances)])
}

Rego Characteristics

• Declarative: You define WHAT conditions to check, not HOW to check them
• Logic-based: Similar to Datalog/Prolog. Uses rules, unification, and queries
• Strengths: Excellent for complex policy composition, reusable rules, graph queries
• Weaknesses: Steep learning curve, counter-intuitive for imperative programmers

Example: Deny EC2 instances without encryption

import "tfplan/v2" as tfplan

# Get all EC2 instances
ec2_instances = filter tfplan.resource_changes as _, rc {
    rc.type is "aws_instance" and
    rc.change.actions contains "create"
}

# Check encryption
unencrypted_instances = []
for ec2_instances as address, instance {
    root_device = instance.change.after.root_block_device[0] else null
    if root_device is not null {
        if root_device.encrypted is not true {
            append(unencrypted_instances, address)
        }
    }
}

# Main rule
main = rule {
    length(unencrypted_instances) == 0
}

Sentinel Characteristics

• Imperative: You write HOW to check conditions step-by-step
• Procedural: Similar to Python/Ruby. Uses loops, conditionals, and variables
• Strengths: Easier for traditional programmers, intuitive control flow
• Weaknesses: More verbose, harder to compose complex policies

Yes, and Many Organizations Do

Common pattern:

• Sentinel: Terraform plan validation in Terraform Cloud
• OPA: Kubernetes admission control with Gatekeeper
• OPA: API gateway authorization with Envoy

Each tool plays to its strengths. There's no requirement to pick just one.

Why Migrate?

• Moving away from Terraform Cloud/Enterprise
• Need broader policy coverage (Kubernetes, APIs)
• Want open-source licensing

Migration Strategy

1. Translate policies: Rewrite Sentinel policies in Rego (no automated converter exists)
2. Use Conftest: Run OPA policies against Terraform plans using Conftest
3. Test in parallel: Run both Sentinel and OPA during transition period
4. CI/CD integration: Replace Terraform Cloud checks with GitHub Actions + OPA

# Example: OPA with Conftest for Terraform
# .github/workflows/terraform-policy.yml
name: Terraform Policy Check
on: [pull_request]
jobs:
  policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Conftest
        run: |
          wget https://github.com/open-policy-agent/conftest/releases/latest/download/conftest_linux_amd64.tar.gz
          tar xzf conftest_linux_amd64.tar.gz
          sudo mv conftest /usr/local/bin/
      - name: Run Terraform Plan
        run: terraform plan -out=tfplan.binary
      - name: Convert to JSON
        run: terraform show -json tfplan.binary > tfplan.json
      - name: Test with Conftest
        run: conftest test tfplan.json

Why Migrate?

• Adopting Terraform Cloud/Enterprise
• Want native Terraform integration
• Team prefers imperative syntax

Migration Strategy

1. Rewrite policies: Translate Rego to Sentinel (manual process)
2. Import to TFC: Upload Sentinel policies to Terraform Cloud policy sets
3. Test thoroughly: Validate behavior matches OPA policies
4. Deprecate OPA gradually: Keep OPA for non-Terraform use cases (K8s, APIs)