Sentinel in action: Policy as code for secure Terraform workflows in HCP

by Mahendran Selvakumar

Day 1 · Festival Pavilion, Fort Mason · Cloud Engineering Track · 30 min · 3 min read

Infrastructure as Code Cloud Architecture

TL;DR

Mahendran Selvakumar demonstrated Sentinel policy-as-code in HCP Terraform, walking through advisory, soft mandatory, and hard mandatory enforcement levels, then showing live policy checks catch EBS encryption disabled, port 22 open to 0.0.0.0/0, and public S3 access before apply runs. He also covered ephemeral resources, write-only arguments, and ephemeral workspaces, three Terraform features that keep passwords and access keys out of plan and state files and auto-destroy dev environments on a timer.

Sentinel Enforcement Levels

▶ Watch (00:40)

Sentinel policy enforcement runs at three levels. Advisory issues a warning but lets terraform apply proceed. Soft mandatory fails the check, but a user with approver access can override it and proceed anyway. Hard mandatory is a stop. If a hard mandatory policy fails, the apply cannot run.

Policy sets group multiple Sentinel policies, each with its own enforcement level. A set can mark EBS encryption as hard mandatory while flagging a missing tag as advisory. The set is then scoped to a project or workspace in HCP Terraform.

Pre-Written Policies and Compliance Benchmarks

▶ Watch (02:48)

HashiCorp and AWS jointly maintain a library of pre-written Sentinel policies. They cover CIS Foundation benchmarks 1.2, 1.4, and 3.0, plus the AWS Foundational Security Best Practices benchmark. Each policy ships with working code. Pulling one from the registry gives an immediately usable rule, and the enforcement level can be changed from advisory to hard mandatory without touching the logic.

Two examples from the library: CloudTrail S3 buckets must have access logging enabled, and EC2 instances must not have a public IPv4 address. Both are available as ready-to-attach policy set entries.

Demo: Catching Non-Compliant Terraform Code

▶ Watch (04:41)

Selvakumar set up two repositories: Terraform code with deliberate violations (EBS encryption false, port 22 open to 0.0.0.0/0, S3 public access enabled) and a Sentinel policy file assigning enforcement levels to each rule. After attaching the policy set and triggering a workspace run, the Sentinel blocking EBS, SSH, and S3 violations (07:21) appeared immediately after the plan phase.

Hard mandatory failures on EBS encryption and the SSH rule blocked apply entirely. The S3 advisory policy flagged but did not stop the run. Fixing the violations in Terraform code is the only path forward when hard mandatory is in play.

Ephemeral Values and Workspaces

▶ Watch (09:04)

Terraform’s ephemeral block keeps secrets out of plan and state files. Declare an AWS Secrets Manager secret inside an ephemeral block and the value exists only during the active run. The same applies to ephemeral = true on variables and outputs. Write-only arguments go one step further: the write-only argument version rotation demo (16:01) showed changing a version number from 1 to 2 triggering an RDS password rotation without the password ever appearing in state.

Ephemeral workspaces add a timeout. Set one, and HCP Terraform destroys the environment automatically, cutting manual cleanup for dev and test stacks.

Notable Quotes

without governance uh it will be risky. Mahendran Selvakumar · ▶ 0:26

Key Takeaways

Sentinel’s three enforcement levels let teams warn on minor issues and hard-block critical ones like open SSH or unencrypted EBS.
HashiCorp’s pre-written policy library covers CIS 1.2, 1.4, and 3.0 benchmarks, removing the need to write compliance rules manually.
Ephemeral resources and write-only arguments keep secrets out of Terraform state and plan files without breaking rotation workflows.

Filed under

Infrastructure as Code Cloud Architecture