Policy Enforcement using Sentinel OPA Part 1

So far we’ve built the foundation of HCP Terraform — workspaces, teams, permissions, and the private registry. In this lesson we shift focus to one of HCP Terraform’s most powerful capabilities: automated policy enforcement on every Terraform run. This is where governance meets automation. For teams that provision infrastructure continuously, policy enforcement ensures configuration mistakes don’t become security incidents or unexpected costs. There’s a lot to cover, so let’s dive in.

Why policy enforcement matters

Imagine a developer applies Terraform that creates storage, a database, and networking:

terraform apply

The run succeeds, but the S3 bucket was inadvertently made public or a security group is overly permissive. Terraform did exactly what the code specified—no guardrails prevented a risky deployment. Policy enforcement evaluates a plan before apply and stops unsafe or non-compliant changes from being provisioned. It moves checks earlier in the lifecycle so governance is automatic, consistent, and versioned.

What is “policy as code”?

Codified rules: Security, compliance, and operational policies are written in a machine-evaluable language instead of living in spreadsheets or wiki pages.
Version-controlled: Policies are stored in VCS repositories, reviewed via pull requests, and managed with the same workflows as your infrastructure code.
Automatically enforced: Policies are evaluated on every Terraform run, removing dependence on manual reviews or tribal knowledge.

An infographic titled "Policy as Code" with a purple theme showing three framed panels. Each panel (Codified Rules, Version Controlled, Automatically Enforced) has an icon and brief text explaining policies written as code, stored in version control, and enforced automatically.

Policy-as-code applies the same automation and source-control discipline we used for infrastructure to governance itself.

Terraform runs: with and without policies

Terraform runs without policies:

Developer pushes Terraform config to HCP Terraform.
Run flow: plan → apply → managed infrastructure.
Nothing intervenes between plan and apply to validate safety or compliance beyond the plan syntax and provider acceptance.

Terraform runs with policy enforcement:

After a successful plan, the plan data is handed off to a policy check phase.
A policy engine evaluates the planned changes against your organization’s rules (operational, security, financial).
Only if all required policies pass will the run proceed to apply and create managed resources.

An infographic titled "Terraform Run With Policies" showing a workflow from "Infrastructure As Code" through Plan → Policy Checks → Apply to "Managed Infrastructure." Below the flow are policy categories (Operational, Security, Financial) shown with checkmarks.

Policies act as a gate — nothing is provisioned until the checks permit it.

Zooming into the policy check phase

During policy checks, the engine inspects the plan output (what Terraform intends to change) and evaluates your policies against that data:

Failed policies can block the apply depending on the enforcement level you choose.
Sentinel policies can access cost estimation data from HCP Terraform, allowing policies to reject plans that exceed cost thresholds.
If the plan itself fails, policies are not evaluated because there is no valid plan to inspect.

Policies run only on successful plans and execute after the plan phase but before apply. If the plan fails, policy checks are skipped.

A purple-themed infographic titled "Policy Check" showing four short points about how policies evaluate plan data before infrastructure is created, can block applies, and can access cost estimates. Each point is displayed in rounded callouts with icons on a dark purple background.

Two frameworks supported in HCP Terraform

HCP Terraform supports both HashiCorp Sentinel and Open Policy Agent (OPA). Choose the one that best fits your organization — or use both where appropriate.

Framework	Maintainer	Policy language	Best fit / notes
Sentinel	HashiCorp	Sentinel	Tight integration with HashiCorp products, built-in integrations and example policies; designed for multi-data-point rules across HashiCorp tooling.
OPA (Open Policy Agent)	CNCF / community	Rego	Broad cloud-native ecosystem support (Kubernetes, Envoy, CI systems); easy to reuse policies across different tools and platforms.

Which to pick? Sentinel gives native HashiCorp integration; OPA delivers broader reuse across cloud-native tools. Both can express powerful checks over Terraform plan data.

Example policies: Sentinel vs. Rego

Seeing actual policy examples helps demystify how policies inspect plans and block bad changes. Below are two representative policies that implement the same high-level check: prevent SSH or ingress open to the entire internet. Sentinel example (GCP): ensure SSH access is not allowed from the internet

import "tfplan/v2" as tfplan

unsupported_source_ranges = [
  "::/0",
  "0.0.0.0",
  "0.0.0.0/0",
]

firewall_resources = filter tfplan.resource_changes as _, rc {
  rc.type is "google_compute_firewall" and
  rc.mode is "managed" and
  (rc.change.actions contains "create" or rc.change.actions contains "update")
}

deny_public_ssh_access = rule {
  all firewall_resources as _, fw {
    # For every 'allow' block in the firewall rule:
    all fw.change.after.allow as _, allow {
      # If the allow block permits port 22, every source range must not be a wide-open address.
      not (allow.ports contains "22") or
      all fw.change.after.source_ranges as _, r {
        r not in unsupported_source_ranges
      }
    }
  }
}

main = rule {
  deny_public_ssh_access
}

Key points:

Imports plan data via tfplan/v2 to inspect changes.
Filters for managed firewall resources being created or updated.
Ensures any rule that allows port 22 does not include a wide-open source range.
If main evaluates to false, the policy fails and can block the run.

OPA / Rego example (AWS): detect security groups with 0.0.0.0/0 ingress

package terraform.policies.public_ingress

import input.plan as plan

deny[msg] {
  r := plan.resource_changes[_]
  r.type == "aws_security_group"
  r.change.after.ingress[_].cidr_blocks[_] == "0.0.0.0/0"
  msg := sprintf("%v has 0.0.0.0/0 as allowed ingress", [r.address])
}

Key points:

Rego examines input.plan and iterates resource changes.
Finds aws_security_group resources whose ingress includes 0.0.0.0/0.
Emits deny messages for any offending resource; the presence of denies causes the policy to fail.

Both examples follow the same pattern:

Read the plan data.
Identify relevant resource changes.
Assert conditions that must hold (or produce deny messages).
Return pass/fail (or deny messages) that determine whether the run proceeds.

Policies only run on successful plans. If the plan fails, policy checks are skipped because there is no valid plan to evaluate.

These examples are consistent with official guidance from HashiCorp: https://developer.hashicorp.com/terraform/cloud-docs/policy-and-governance. They show how policy-as-code reads planned changes, evaluates conditions, and produces a pass/fail outcome that controls deployment. Next up (in subsequent lessons) we’ll cover enforcement modes, how to attach policies to workspaces, and practical policy examples your teams can reuse.

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Policy Enforcement using Sentinel OPA Part 1

Why policy enforcement matters

What is “policy as code”?

Terraform runs: with and without policies

Zooming into the policy check phase

Two frameworks supported in HCP Terraform

Example policies: Sentinel vs. Rego

Watch Video

​Why policy enforcement matters

​What is “policy as code”?

​Terraform runs: with and without policies

​Zooming into the policy check phase

​Two frameworks supported in HCP Terraform

​Example policies: Sentinel vs. Rego

Watch Video

Why policy enforcement matters

What is “policy as code”?

Terraform runs: with and without policies

Zooming into the policy check phase

Two frameworks supported in HCP Terraform

Example policies: Sentinel vs. Rego