Securing Infrastructure: Terraform & Sentinel
As cloud infrastructure scales across multi-tenant environments, enforcing security, compliance, and cost governance policies manually becomes impossible. Developers using Infrastructure-as-Code (IaC) tools like Terraform can accidentally provision publicly accessible S3 storage buckets, unencrypted database instances, or oversized Virtual Machines.
Traditional compliance checking relies on post-deployment cloud security scanners (like AWS Security Hub or Prisma Cloud). However, post-deployment remediation happens after vulnerable resources are already live in production. Sentinel is HashiCorp's embedded Policy-as-Code framework. Sentinel embeds automated guardrails directly into the Terraform execution pipeline between terraform plan and terraform apply. This guide details Sentinel policy syntax, compliance enforcement levels, and custom security rules.
Mental Model: Policy-as-Code vs Post-Deployment Compliance Scans
Post-deployment compliance tools audit live infrastructure periodically. If a developer provisions an unencrypted AWS RDS database via Terraform, post-deployment tools alert security teams 24 hours later, requiring complex manual teardowns.
Sentinel Policy-as-Code shifts compliance enforcement left into the CI/CD deployment pipeline.
During terraform plan, Sentinel inspects the generated execution plan (tfplan.json). It evaluates security policies (e.g., "All S3 buckets must have AES-256 encryption enabled") BEFORE any cloud resource is created. If a plan violates a policy, Sentinel blocks terraform apply immediately, preventing security vulnerabilities from reaching production cloud environments. For zero-trust infrastructure patterns, review zero trust architecture cloud native microservices and mastering gitops argocd fluxcd kubernetes.
Quick reference
- Policy-as-Code shifts security and compliance checks left into pre-apply CI/CD execution pipelines.
- Sentinel evaluates terraform plan JSON data before cloud API calls execute.
- Prevents creation of unencrypted storage buckets, open security groups, and un-tagged VMs.
- Codifies corporate governance rules into version-controlled policy repositories.
- Reduces manual security review bottlenecks while maintaining developer velocity.
Remember this
Embed Sentinel policy-as-code guardrails into Terraform pipelines to block non-compliant cloud resources before apply.
Sentinel Policy Language: Imports, Rules, & Logic Evaluation
Sentinel uses a lightweight, Turing-complete domain-specific language designed specifically for policy evaluation.
A Sentinel policy consists of three parts:
1. Imports: Modules that expose Terraform plan data (tfplan/v2, tfconfig/v2, tfrun).
2. Helper Functions: Custom functions that filter resource collections.
3. Rules: Boolean condition expressions (rule { condition }).
1import "tfplan/v2" as tfplan2 3main = rule {4 all tfplan.resources.aws_s3_bucket as _, bucket {5 bucket.applied.server_side_encryption_configuration is not null6 }7}When main evaluates to true, Sentinel passes the plan; if false, Sentinel fails execution based on configured enforcement levels.
Quick reference
- Imports load structured JSON data models for Terraform plans, state files, and run metadata.
- Rule blocks define boolean assertions (main = rule { condition }) evaluated during plan runs.
- Supports quantification expressions (all, any) to iterate over resource arrays easily.
- Enforces strict data typing and null checking to prevent evaluation runtime exceptions.
- Sentinel CLI allows developers to run unit tests (sentinel test) on policies locally.
Remember this
Write Sentinel policies using imports and quantifier rules to validate terraform plan attributes.
Writing Guardrail Rules: Enforcing Mandatory Cloud Tags & S3 Encryption
Production cloud governance requires enforcing mandatory metadata tagging (e.g., Environment, Owner, CostCenter) and strict security encryption settings.
To enforce mandatory tags across all EC2 instances and S3 buckets, Sentinel iterates over all resources in tfplan.resources. If any resource is missing required tag keys, Sentinel captures the offending resource addresses and returns a detailed failure message.
Similarly, Sentinel policy rules can enforce CIDR range restrictions (blocking 0.0.0.0/0 ingress rules on SSH port 22) or restrict EC2 instance types (t3.micro to m5.large) to prevent cloud cost overruns.
Quick reference
- Enforce mandatory resource tags (Environment, CostCenter) for accurate cloud billing allocation.
- Block public ingress rules (0.0.0.0/0) on sensitive administration ports (SSH 22, RDP 3389).
- Require customer-managed KMS key encryption on database volumes and storage buckets.
- Restrict max virtual machine instance sizes to prevent accidental expensive instance provisioning.
- Return descriptive error messages identifying offending resource addresses to developers.
Remember this
Draft guardrail policies to enforce mandatory resource tags, restricted security groups, and storage encryption.
Policy Enforcement Levels: Advisory, Soft-Mandatory, & Hard-Mandatory
Sentinel supports three Policy Enforcement Levels, allowing organizations to introduce governance rules gradually without disrupting active developer teams:
1. Advisory: Log warnings when a policy fails, but allow terraform apply to proceed. Ideal for testing new policy rules.
2. Soft-Mandatory: Block terraform apply on failure, but allow authorized organization administrators to override the failure in Terraform Cloud UI with a logged justification.
3. Hard-Mandatory: Strictly block terraform apply on failure. Overrides are impossible. Reserved for non-negotiable compliance rules (e.g., GDPR data retention or encryption mandates).
Quick reference
- Advisory level logs warnings without blocking deployments, allowing policy dry-runs.
- Soft-Mandatory level blocks apply by default but permits authorized administrator overrides.
- Hard-Mandatory level strictly blocks apply with zero override capability for core security rules.
- Gradually promote new policies from Advisory to Soft-Mandatory to Hard-Mandatory over time.
- Audit log entries record administrator override justifications for compliance review.
Remember this
Utilize Advisory, Soft-Mandatory, and Hard-Mandatory enforcement levels to roll out governance policies safely.
Key takeaway
To test Sentinel policies, install Sentinel CLI (brew install sentinel). Write a policy file, run sentinel test, and verify pre-apply policy checks block non-compliant Terraform plans.
Related Articles
Explore this topic