HCP Terraform

A run pauses after its plan while your operators look at what it’ll do and turn their keys. The verdict goes back to HCP Terraform as the run task’s result: passed lets the run apply, failed stops it. Terraform Enterprise works the same way.

Actions

Every organization gets this one when it issues its first Terraform connection. An admin can change any field on the dashboard.

Action	Keys	Mode	Request TTL	Arm window	Code TTL	Self approval
terraform.apply	2	counted	50m	60s	15m	denied

Set it up

1. In Outis, open the HCP Terraform integration and issue a connection. Give it your HCP Terraform organization’s name, exactly as HCP Terraform spells it. For Terraform Enterprise, give your install’s hostname too. It has to be a public name Outis can reach over the internet, so an IP address, localhost or an internal name like tfe.corp or tfe.internal gets refused.
2. Outis shows two values: an endpoint URL like https://api.outis.tech/integrations/terraform/run-task/tfrt_... and an HMAC key. Copy both. The key is shown once; if you lose it, issue a new connection and delete the old one.
3. In HCP Terraform, open your organization’s Settings, then Run tasks, and create a run task. Paste the endpoint URL and the HMAC key. HCP Terraform sends a test request when you save, and Outis answers it.
4. In each workspace you want gated, open Settings, then Run tasks, and attach the task at the Post-plan stage (or Pre-apply) with Mandatory enforcement.

The connection answers for runs in that one HCP Terraform organization. A key pasted into a different organization’s run task gets every run refused.

Which stage

Post-plan or pre-apply. Both have a plan to show and haven’t applied yet. Post-plan asks as soon as the plan exists; pre-apply asks once someone has confirmed the apply in HCP Terraform, so a plan nobody meant to apply never reaches your operators.

A task attached at pre-plan fails with a message saying so, because there’s no plan to show yet. Post-apply fails too, since by then there’s nothing left to approve.

What your operators see

The panel reads TERRAFORM APPLY over the workspace name. Destruction comes first: DEL is resources destroyed and RPL is resources replaced, then ADD and CHG. Anything destroyed or replaced makes the request critical. The notification carries the run message, the counts and the digest.

The request carries these params, and the digest covers all of them:

Param	What it is
organization, workspace, run	Where the run is
stage	post_plan or pre_apply
create, update, replace, delete	The plan’s resource counts. A delete and create in either order is a replace
speculative	true for a plan that can’t apply
commit	The short commit sha, when the run came from VCS
plan	sha256: and the SHA-256 of the plan JSON

While the request is open, the run shows running with a link to it, refreshed every four minutes. Once it’s decided, the run shows passed with the approvers’ names, or failed saying it was denied, expired or withdrawn. If the task accepts structured outcomes, the result also carries the approvers, the operation hash and the plan hash.

The 60 minute ceiling

HCP Terraform gives a run task 60 minutes at most, and errors it after 10 minutes without an update. Outis reports progress every four minutes, and the action’s request TTL is 50 minutes, so a request nobody finishes expires in Outis and lands as failed before HCP Terraform gives up. If you raise the TTL past 60 minutes, HCP Terraform times the task out first.

What happens then depends on the enforcement level. With mandatory enforcement, a failed task or one that times out stops the run, so that’s the level that actually holds an apply. With advisory enforcement, HCP Terraform records the failure and the run carries on anyway, which is handy for trying Outis out on a workspace and useless for stopping anything.

The run’s token

Each run task carries a one-run token. Outis seals it with the request and uses it for exactly two things: reading that run’s plan, and answering that run’s task result. It never applies, discards or queues a run, and never calls any other HCP Terraform endpoint. The token isn’t in the params, on the panel, in a log or in a webhook, and HCP Terraform’s plan download link is fetched without it. Outis doesn’t hold an HCP Terraform API token of its own.

Signatures

HCP Terraform signs each run task with the connection’s HMAC key: X-TFC-Task-Signature is a hex HMAC-SHA512 of the raw body. Outis checks it before reading anything, and a run task with no signature is refused. The connection id in the URL picks the key, so each organization’s key only ever signs into its own requests.

Who asked

HCP Terraform names the user who started the run. Outis doesn’t match HCP Terraform users to operators yet, so the request’s requester reads tfc: and that username, and the summary says it wasn’t matched. With self approval denied, that means any two eligible operators can approve, including whoever started the run.