Infrastructure as code solved the provisioning consistency problem. Teams could define exactly what infrastructure should exist and deploy it repeatedly from version-controlled configuration.
But infrastructure as code also introduced a new problem: it made it easier to accidentally provision infrastructure that violates security, compliance, or cost policies and to do it at scale, automatically, before anyone noticed.
HashiCorp Sentinel is the answer to that problem. It is a policy-as-code framework that lets organizations define governance rules in code and enforces those rules automatically on every Terraform plan, before infrastructure is created or modified.
This guide explains what Sentinel is, how policy as code differs from traditional policy management, how Sentinel integrates with the HashiCorp ecosystem, the core concepts you need to understand, and how to write a basic Sentinel policy.
What Is HashiCorp Sentinel?
Sentinel is HashiCorp’s embeddable policy-as-code framework. It allows organizations to define fine-grained, logic-based policies in a purpose-built language and enforce them automatically as part of infrastructure provisioning and operations workflows.
Sentinel integrates with the enterprise and HCP (HashiCorp Cloud Platform) versions of Terraform, Vault, Consul, and Nomad. Its most widely used integration is with Terraform where Sentinel policies run automatically on every Terraform plan, checking whether the proposed infrastructure changes comply with defined rules before any changes are applied.
The framework was announced by HashiCorp in 2017 and described by co-founder and CTO Armon Dadgar as a natural extension of the infrastructure-as-code philosophy: if you can capture infrastructure configuration as code, you should also be able to capture governance and compliance requirements as code with the same benefits of version control, testing, and automation.
What Is Policy as Code?
Policy as code (PaC) is the practice of expressing organizational policies, security requirements, compliance rules, operational standards, cost controls as programmatic code that can be automatically evaluated, tested, and enforced.
Traditional policy management relies on documentation, training, and periodic manual review. A security policy that says “all S3 buckets must have server-side encryption enabled” lives in a PDF, gets communicated in onboarding sessions, and is checked during quarterly audits.
Policy as code expresses that same requirement as a rule that runs automatically on every Terraform plan. If someone writes a Terraform configuration that creates an unencrypted S3 bucket, the policy catches it before the plan is applied before the bucket exists.
The shift from reactive to proactive is the critical difference. Traditional policy tools (AWS Config, Cloud Custodian, and similar) detect violations after resources are created at step 4 of the infrastructure lifecycle. Sentinel prevents violations from being created at step 2, before applying.
The benefits of expressing policy as code follow directly from the benefits of any code: it can be version controlled, reviewed in pull requests, tested automatically, deployed consistently, and audited precisely. A policy in a PDF cannot be tested. A Sentinel policy can.
Where Sentinel Fits in the HashiCorp Ecosystem
Sentinel is not a standalone product in the same way Terraform or Vault are. It is closer to a framework or language that is embedded in other HashiCorp enterprise products.
| HashiCorp Product | What Sentinel Governs | Example Policy Use Cases | Availability |
| Terraform (HCP/Enterprise) | Infrastructure provisioning plans | Enforce resource tagging; restrict instance types; require encryption; limit cloud regions | HCP Terraform + Terraform Enterprise |
| Vault (Enterprise) | Secrets access and operations | Control access to secrets based on role; restrict which paths are accessible; enforce MFA | Vault Enterprise |
| Consul (Enterprise) | Service mesh configuration and access | Restrict service registration; enforce mutual TLS; control access control list (ACL) rules | Consul Enterprise |
| Nomad (Enterprise) | Job scheduling and workload configuration | Only allow Docker-based jobs; restrict resource requests; enforce namespace isolation | Nomad Enterprise |
Terraform is the most common entry point. Teams that are already using Terraform and want automated governance of their infrastructure changes add Sentinel policies to their HCP Terraform or Terraform Enterprise workspace.
From that foundation, the same Sentinel language and workflow can be applied across Vault, Consul, and Nomad.
Core Sentinel Concepts
Policies
A policy is a single Sentinel file containing rules that evaluate to true or false. The policy passes if all rules evaluate to true; it fails if any rule evaluates to false.
Policies are written in the Sentinel language a purpose-built, high-level language designed to be readable and writeable by security and compliance professionals who may not have a software development background. The syntax is intentionally similar to natural language and avoids the complexity of general-purpose programming languages.
A simple Sentinel policy that requires all EC2 instances to use approved AMIs looks like this:
import “tfplan/v2” as tfplan
allowed_amis = [“ami-0c55b159cbfafe1f0”, “ami-0b898040803850657”]
main = rule {
all tfplan.resource_changes as _, rc {
rc.type is not “aws_instance” or
rc.change.after.ami in allowed_amis
}
}
The policy imports the Terraform plan data, defines a list of allowed AMIs, and then asserts that every EC2 instance in the plan uses one of the allowed AMIs. If any instance uses a non-approved AMI, the main rule evaluates to false and the policy fails.
Enforcement levels
Sentinel replaces a binary pass/fail with three enforcement levels that give organizations flexibility in how strictly policies are applied.
Hard-mandatory: The policy must pass. If it fails, the Terraform run cannot proceed. There is no override mechanism. This level is appropriate for absolute security and compliance requirements encryption at rest, network isolation rules, regulatory data residency requirements.
Soft-mandatory: The policy must pass by default. If it fails, a designated operator can override the failure with an explicit approval. This level is appropriate for guidelines where exceptions are legitimate but must be explicitly acknowledged cost controls, non-critical tagging requirements.
Advisory: The policy runs and the result is logged, but failure does not block the run. This level is appropriate for early-stage policy development where you want visibility into current compliance before enforcing hard requirements, or for informational rules where awareness is the goal.
Policy sets
A policy set is a collection of policies applied to one or more workspaces. In HCP Terraform and Terraform Enterprise, policy sets are defined in configuration files and can be scoped to specific workspaces, projects, or applied globally across all workspaces in an organization.
This allows different governance requirements to apply to different contexts. Production workspaces might have hard-mandatory policies for encryption, instance type restrictions, and approved AMIs. Development workspaces might have the same policies at the advisory level, giving developers visibility without blocking experimentation.
Imports
Imports provide access to data that policies use to make decisions. Without imports, a Sentinel policy has no visibility into the infrastructure being proposed; it cannot evaluate the state of a Terraform plan.
Standard Sentinel imports for Terraform include tfplan (the Terraform plan, showing what changes are proposed), tfstate (the current Terraform state), and tfconfig (the Terraform configuration before evaluation). Each import exposes specific data about the infrastructure in a structured format that policies can query.
Beyond these standard imports, Sentinel can connect to external systems. The http import allows policies to query external APIs. A policy could check an internal CMDB to verify that a resource tag value corresponds to a valid cost center, or query an approved software catalog to verify that a container image has been through the security scanning process.
Custom modules allow commonly used policy logic to be centralized and reused across multiple policies analogous to modules in Terraform itself.
How Sentinel Works in a Terraform Workflow
When Sentinel is configured in HCP Terraform or Terraform Enterprise, the workflow for every Terraform run is as follows. A developer writes or updates a Terraform configuration and submits a run to the workspace.
Terraform generates the plan a description of what changes will be made to infrastructure if the configuration is applied.
Sentinel evaluates all policies in the policy sets assigned to that workspace against the plan. Each policy receives the plan data via imports and evaluates its rules. If all policies pass: the run proceeds to the apply stage (or waits for manual approval if the workspace is configured to require it).
If a soft-mandatory policy fails: an operator can review the failure and choose to override it with an explicit approval, or block the run. The override is logged.
If a hard-mandatory policy fails: the run is blocked. The developer must modify the configuration to resolve the violation and resubmit. The developer receives feedback at the plan stage before any infrastructure change has been made. This shifts governance from reactive detection to proactive prevention.
Common Sentinel Use Cases for Terraform
Mandatory resource tagging
Resource tagging is a foundational infrastructure governance requirement: cost allocation, ownership identification, environment classification, and compliance reporting all depend on consistent tagging.
A Sentinel policy can enforce that every taggable resource in a Terraform plan has a defined set of required tags — Environment, Owner, Project, CostCenter and that those tags are not null or empty. Without Sentinel, tagging requirements are enforced only during code review, which is inconsistent and misses automation.
Restricting instance types and sizes
Unconstrained cloud instance selection is a frequent source of unexpected cost. Developers provisioning oversized instances for development workloads, or inadvertently using expensive GPU instances, add cost without governance visibility.
A Sentinel policy can define an allowlist of approved instance types for each environment. A production workload might allow t3.large through m5.xlarge. A development workspace might be restricted to t3.micro through t3.large. Any plan requesting an instance type outside the approved list fails the policy.
Enforcing encryption
Encryption at rest and in transit is a common compliance requirement PCI-DSS, HIPAA, SOC 2, and most regulatory frameworks mandate it for sensitive data.
A Sentinel policy can check that all RDS databases have storage encryption enabled, all S3 buckets have server-side encryption configured, all EBS volumes are encrypted, and all resources use approved KMS key ARNs. This converts a compliance requirement from a documentation obligation into an automatic enforcement control.
Restricting cloud regions
Data residency requirements particularly under GDPR and national data sovereignty regulations require that certain data remain within specific geographic regions.
A Sentinel policy can restrict which AWS regions, Azure locations, or GCP zones are allowed for resource provisioning. Any plan that would create resources outside the approved region list fails the policy preventing accidental data residency violations from Terraform misconfiguration.
Cost estimation controls
HCP Terraform includes cost estimation that projects the monthly cost of proposed infrastructure changes. Sentinel policies can access this cost data and enforce cost thresholds blocking runs that would exceed a defined monthly cost increase, or requiring additional approval for high-cost changes.
This converts cost governance from a periodic finance review into an automatic per-run check.
Sentinel vs Open Policy Agent (OPA)
Open Policy Agent (OPA) is the main alternative to Sentinel for policy as code in Terraform environments.
OPA is open-source, vendor-neutral, and uses the Rego policy language. It integrates with Terraform through tools like Conftest and OPA’s native Terraform provider. It can also be used for policy enforcement in Kubernetes, CI/CD pipelines, and other non-HashiCorp systems. Sentinel is proprietary, closed-source, and exclusively integrated with HashiCorp enterprise products.
The Sentinel language is generally considered more readable and accessible than Rego, particularly for security and compliance professionals without a software engineering background. Its deep integration with Terraform Enterprise and HCP Terraform provides a tighter feedback loop in those environments.
The practical choice between them is usually driven by the existing toolchain. Organizations already using HCP Terraform or Terraform Enterprise typically use Sentinel. Organizations that need policy enforcement across non-HashiCorp tools, or that prefer open-source solutions, typically use OPA. Both can coexist Sentinel for HashiCorp-specific policies, OPA for broader infrastructure governance.
Getting Started with Sentinel
The Sentinel CLI is available for macOS, Linux, and Windows and can be used to develop and test policies locally before deploying them to HCP Terraform or Terraform Enterprise.
The standard development workflow is: write a policy locally, generate Sentinel mock files from a real Terraform workspace run, test the policy against the mock files using the CLI, iterate until the policy behaves correctly, commit the policy to a version-controlled repository, and connect the repository to HCP Terraform as a policy set.
HashiCorp provides a library of Sentinel policy examples on GitHub; the terraform-foundational-policies repository contains ready-to-use policies for CIS benchmarks, PCI-DSS requirements, and other common standards that can be used directly or adapted as starting points.
The official documentation at developer.hashicorp.com/sentinel provides the complete language reference, import documentation for each HashiCorp product, and a hands-on tutorial series that walks through policy authorship from basics to complex governance requirements.
Final Thoughts
HashiCorp Sentinel represents a meaningful shift in how organizations approach infrastructure governance. Manual review processes do not scale with infrastructure complexity. Periodic audits find violations after the fact. Sentinel moves enforcement to the point of change automatically, consistently, and before infrastructure is created.
For teams using Terraform at enterprise scale, Sentinel addresses one of the most consistent gaps in infrastructure as code practice: the ability to codify governance requirements with the same rigour, auditability, and automation that infrastructure itself benefits from.
For data platform and cloud infrastructure teams building on HashiCorp tooling managing data lake infrastructure, cloud data warehouse provisioning, or data pipeline environments through Terraform Sentinel provides the automated governance layer that ensures provisioned infrastructure meets security, compliance, and cost requirements without introducing manual review bottlenecks into the deployment pipeline.