Why This Matters

As infrastructure as code grows in complexity, enforcing policies programmatically is no longer optional—it’s essential. In HCP Terraform, you can define and enforce policies using two policy-as-code frameworks:

• Sentinel

• OPA (Open Policy Agent)

When teams begin adopting policy as code, I often hear the same questions come up:

• Which one should I choose—Sentinel or OPA—if I’m just getting started?

• If I want to extend policies across multiple HashiCorp products, which framework scales better?

• What are the limitations of each option, and how do I make the right choice for my environment?

This blog explores how both Sentinel and OPA integrate with HCP Terraform, the types of data they expose, and the key considerations to help you choose the best approach for your infrastructure.

Overview: Policy-as-Code in HCP Terraform

The diagram illustrates how different teams collaborate to enforce policies during the resource provisioning workflow. The Security/Compliance team and the Platform/DevOps team jointly define policies, which are applied at the workspace level. When the Application team initiates resource provisioning, these policies are automatically evaluated after the Terraform plan stage and before the Terraform apply stage. This ensures that security and compliance checks are performed early in the process, reducing the risk of misconfigurations or policy violations before any infrastructure changes are applied.

Key Concept in HCP Terraform

To help you better understand the Policy as Code (PaC) in HCP Terraform, I have outlined some key concepts below. If you’re already familiar, go ahead and jump straight to the Introduction section.

• Policies and Policy Sets

  • Policies are rules that HCP Terraform enforces on Terraform runs. You can define policies using either the Sentinel or OPA frameworks.

  • Policy sets are collections of policies. You can define:

    • Scope: apply globally (to the whole HCP Terraform organization) or to the specific projects and workspaces in your organization. You can also define exclusion to exclude specific workspaces from using this policy set.

    • Enforcement level: Advisory or mandatory.

• HCP Terraform Projects and Workspaces

• VCS connections

  • How to connect to VCS

  • Supported VCS providers

Introduction to Sentinel

Sentinel is a language and framework for policy built to be embedded in existing software to enable fine-grained, logic-based policy decisions. A policy describes under what circumstances certain behaviors are allowed. Sentinel is an enterprise-only feature of HashiCorp Consul, Nomad, Terraform, and Vault.

For more information about Sentinel, visit the official Sentinel documentations and Sentinel tutorials.

• Policy Libraries (beta)

HashiCorp provides a collection of pre-written Sentinel policies available through the registry. You can refer to the pre-written policy library reference ffor a complete list of available policy sets, or explore the policies directly in the registry.

Note: This feature is currently in beta. It is recommended to avoid using it in production environments, or to exercise caution and apply your best judgment when doing so.

How to Use — Tutorial

To use pre-written Sentinel policies from the registry, refer to the Run pre-written Sentinel policies guide for step-by-step instructions.

• Custom Sentinel

You define policies with the Sentinel policy language and use imports to pare the Terraform plan, state, run and configuration. Refer to Define customer Sentinel policies for details and tutorial.

Introduction to OPA

You can write OPA policies using the Rego policy language, which is the native query language for the OPA framework. Refer to the following topics in the OPA documentation for additional information:

• How Do I Write Rego Policies?

• Rego Policy Playground

How to Use — Tutorial

Define Open Policy Agent policies for HCP Terraform

Comparison: Sentinel and OPA

HCP Terraform supports both Sentinel and OPA, this gives teams flexibility in how they implement policy as code. Each framework comes with its own strengths and trade-offs, and you can even run them side by side within the same HCP Terraform workspace.

In the screenshot below, the “Demo-Sentinel-OPA” workspace has both Sentinel policy sets and OPA policy sets attached. Within each framework, you can also assign multiple policy sets, allowing you to combine different rules and controls to meet your organization’s security and compliance requirements.

📸 Screenshot: Workspace run

📸 Screenshot: Sentinel policy sets and OPA policy sets.

Let’s compare the two frameworks—Sentinel and OPA—across the following dimensions:

Adoption and Integration

When choosing between the two frameworks, organizations should weigh factors such as their current infrastructure setup, future scaling plans, the learning curve, and intended use cases. The table below compares Sentinel and OPA from an adoption and integration perspective, with a focus on how easily each can be adopted today while still supporting long-term growth.

• Terraform Data Access

When it comes to actually defining policies, organizations need to be aware of the specific data points available. This becomes especially important when DevOps teams work collaboratively with Security, Compliance, and even Finance teams—for example, to enforce governance rules or cost estimation policies.

• Sentinel: HCP Terraform provides four imports to define policy rules for the plan, configuration, state, and run associated with a policy check.

  • tfplan/v2 - access a Terraform plan, which is the file created as a result of the “terraform plan”

  • tfconfig/v2 - access a Terraform configuration.

  • tfstate/v2 - access the Terraform state .

  • tfrun - access data associated with a run in HCP Terraform.

• OPA: OPA input - HCP Terraform combines the output from the Terraform run and plan into a single JSON file and passes that file to OPA as input.

  • To access the properties from the Terraform plan data in your policies, use input.plan. Use the Retrieve JSON Execution Plan endpoint to retrieve Terraform plan output data.

  • To access properties from the Terraform run, use input.run. Refer to Terraform run data for the properties included in Terraform run output data.

Suggestions and Guidance for Choosing Between Sentinel and OPA

When deciding whether to use Sentinel or Open Policy Agent (OPA) for policy enforcement with Terraform, consider the following factors:

• Product Ecosystem
  If you plan to adopt other HashiCorp products (such as Vault, Consul, or Nomad) in addition to Terraform, Sentinel is often the stronger choice due to its native integration across the HashiCorp stack.

• Infrastructure Coverage
  Evaluate the types of resources and platforms you need to govern with Policy as Code. Also consider how you want to structure your overall policy framework (single platform vs. cross-platform).

  • Sentinel is purpose-built for Terraform and the HashiCorp ecosystem.

  • OPA provides broader cross-platform coverage if you need a consistent policy engine across multiple systems.

• Skills and Expertise
  If your team does not already have experience with OPA and is starting from scratch, Sentinel is typically easier to adopt for Terraform use cases. If you already have OPA in use across your organization, extending it to Terraform may make sense.

• Testing and Policy Lifecycle
  Consider your process for testing, validating, and maintaining policies:

  • Sentinel integrates tightly with Terraform Cloud/Enterprise testing workflows.

  • OPA may require additional tooling to implement a full policy testing and lifecycle pipeline.

• Terraform Data Access
  When writing rules, think about which Terraform data sources you need to enforce policies against:

  • Sentinel: Provides direct access to plan, state, configuration, and run metadata through built-in imports.

  • OPA: Operates on the Terraform plan JSON, giving visibility into proposed infrastructure changes, but with more limited access compared to Sentinel’s deep Terraform integration.

How to implement

Now let’s take a look at how both frameworks—Sentinel and OPA—can be integrated with HCP Terraform. Depending on your team’s experience and the structure of your CI/CD workflows, you have several options for where and how to enforce policies.

#Option 1 - Managing Policies in HCP Terraform

If your organization uses the HCP Terraform portal to centrally manage all policies and policy sets, then this becomes the most straightforward choice. Policies are defined, versioned, and enforced directly within HCP Terraform, giving you a single source of truth for governance across workspaces.

Create Policy

1. HCP Terraform portal—>Choose an organization (e.g. Ting_HCP_Demo)—>Settings—>Policies.

2. Create Sentinel policy

You can configure the following:

• Policy Name – a unique identifier for the policy.

• Enforcement Behavior – defines how the policy is applied (e.g., advisory, soft mandatory, hard mandatory).

• Policy Code – write the policy logic directly in the UI using the Sentinel language.

• (Optional) Policy Set – assign the policy to an existing policy set. Note that policies can only be added to sets within the same framework (e.g., a Sentinel policy must belong to a Sentinel policy set).

  Code Example

  

  

  3. Create OPA Policy

You can configure the following:

• Policy Name – a unique identifier for the policy.

• Enforcement Behavior – defines how the policy is applied (e.g., advisory, mandatory).

• Query: write the rule expression and Policy code in Rego language directly in the UI

• (Optional) Policy Set – assign the policy to an existing policy set. Note that policies can only be added to sets within the same framework (e.g., a OPA policy must belong to a OPA policy set).

Code Example

Now we have created two policies in the “Ting_HCP_Demo” organization. To use those policies, we need to create policy set(s), and attache the policy set(s) to the workspace(s).

Create Policy Set

Policy sets are collections of policies that you can apply globally or to specific projects and workspaces. For each run in the selected workspaces, HCP Terraform checks the Terraform plan against the policy set.

There are three options when choosing a source:

1. Individually managed policies

• Create a policy set with individually managed policies. Choose from the policies that you have created through the UI (described in the above steps).

2. Version control provider

• Choose the vcs that hosts the policies for this policy set.

• You have one or more police file(s) saved in the VCS repo. Works for both Sentinel (*.sentinel) and OPA (*.rego).

3. Automated

• If you only plan to use the API to upload policies for this policy set, you don’t need to connect it to version control. You can add a VCS connection later.

If you choose Option 1 to manage policies in HCP Terraform, then you should choose the “Individually managed policies” option to create a policy set.

From the HCP Terraform portal navigate to the Policy Sets section —> Create Policy Set. From here you can:

• Choose a Policy framework.

• Enter a Name for the policy set.

• Choose the Scope of policies:

  • Policies enforced globally - all the workspaces in this organization (e.g. Ting_HCP_Demo) will be enforced with this policy set.

  • Policies enforced on selected projects and workspaces - choose the project(s) and workspace(s) from the drop-down-list.

• Configure the enforcement behavior.

• Define the exclusive workspace to exclude specific named workspace(s) from the policy set’s scope. Policies in this set will not be enforced on the excluded workspace(s).

• Choose from the list of policies you have previously created through the UI.

#Option 2 - Managing Policies Outside HCP Terraform

If policies are managed externally—for example, through your version control system (VCS)—you can still integrate Sentinel or OPA by running policy checks before the Terraform apply stage. This approach offers greater flexibility in how policies are created, tested, and maintained, but it requires additional tooling and workflow design.

In this guide, we will use a VCS-based workflow as an example, since it is the most commonly adopted use case. As shown below, the HCP Terraform workspace is integrated with the supported VCS tool.

When creating policies through a VCS, you have flexibility in how you manage the policy files. For example, we can consider two common approaches, in this example, we will use GitHub as the VCS tool.

• #case 1: create a set of policies in VCS repo. Create Policy set from the HCP Terraform UI with “Version control provider” option.

• #case 2: create a no-code module, which include both policies, policies sets and terraform configurations.

#case 1 - ONLY create and manage the policy files in the GitHub repo

1. In GitHub, create a repo named “ddr-pac-sentinel-aws”, create two sentinel files as below:

# instance-type.sentinel
# Imports mock data
import "tfplan/v2" as tfplan

param disallowed_types default ["c5n.metal", "c5n.18xlarge"]

# Get all AWS instances from all modules
ec2_instances = filter tfplan.resource_changes as _, rc {
    rc.type is "aws_instance" and
        (rc.change.actions contains "create" or rc.change.actions contains "update")
}

# Rule to restrict instance types
instance_type_disallowed = rule {
    not all ec2_instances as _, instance {
        instance.change.after.instance_type in disallowed_types
    }
}

# Validate if the instance type is not disallowed
main = rule {
    length(ec2_instances) == 0 or instance_type_disallowed
}

2. In HCP Terraform UI, in “Ting_HCP_Demo” organization, navigate to Policy Sets, and click “Create Policy Set”. In this example, we use “Sentinel” , the OPA follows the same process.

   

3. Choose the VCS connection and the repo. Follow the steps to fill in the rest of the information.

   

   

   

   

   

4. Complete.

#case 2 - Create a no-code module, which includes everything

Here is the reference structure used in this example:

• repo - demo-terraform-policy-as-code : this is the no-code module where you defines the resource provision in *.tf files. And define one sentinel policy set and one OPA policy set in the main.tf file in the “platform-shared-resources” folder.

  • In the main.tf file, we use resource “tfc_policy_set” to define the policy set for sentinel and OPA.

  • In each section, we use “vpc_repo” to define the reference to your policy VCS repository.

• repo - ddr-pac-sentinel-aws

  • sentinel files

  • sentinel.hcl file: Defines the running parameters in the event of a policy evaluation through HCP Terraform.

• repo - ddr-pac-opa-aws

  • rego files

  • policies.hcl file: Defines the running parameters in the event of a policy evaluation through HCP Terraform.

Here are the general steps to set up:

1. In GitHub, create repositories, create terraform config files and policy files.

2. In HCP Terraform UI, publish the no-code module to the HCP Terraform registry. Here is the reference and guide about how to create and use no-code modules.

3. In HCP Terraform UI, navigate to the registry, and find out the no-code module you just published, by clicking the “Provision Workspace”, you can kick off the process of provisioning resources with enhanced Sentinel and OPA policies.

Conclusion & Next Steps

HCP Terraform supports both Sentinel and OPA, giving you flexible options for policy enforcement. There’s no single “best” solution—choose the approach that fits your project. You can even use both frameworks together. If you’re new to OPA, starting with Sentinel is recommended for a smoother, more guided experience.

Next Steps:

1. Assess your policy requirements – Determine which framework (Sentinel, OPA, or both) aligns with your project goals.

2. Plan your workspace integration – Decide whether to manage policies internally via HCP Terraform or externally via a VCS workflow.

3. Implement policy sets – Create individually managed policies or import pre-written policies as needed.

4. Test policies – Run policy checks in a staging or pre-apply environment to validate enforcement behavior.

5. Iterate and refine – Continuously improve your policies based on feedback and evolving project requirements.

I have included several links throughout this blog—please take some time to explore them and try out the tutorials.