Documentation / Infrastructure runs

Policy as code

OPA policy sets that check every plan before it applies: making one from the dashboard or a repository, advisory and mandatory, overrides, and the pull request.

A policy set checks every plan in the workspaces it covers before the plan can be applied. Policies are written in Rego and evaluated with OPA against the plan's JSON. Sentinel is HashiCorp's own language, and it will not be here.

An owner or an admin goes to Terraform → Policy sets, chooses New policy set, and fills in Create policy set. A set needs a name, a source, and the workspaces it covers.

There are two sources.

• One Rego policy. Paste the Rego into the Rego policy field, or choose Upload a .rego file of up to 1 MiB to fill it, and edit it there before you save. Then give the OPA query the engine should evaluate, for example data.terraform.deny, and an Enforcement level.

• A repository. Choose a connected VCS provider, the repository, a branch, and the Policy directory that holds the set. That directory carries a policies.hcl in HCP Terraform's format, one policy block per policy, with the Rego files beside it. A policy with no enforcement_level is advisory. To use a repository, first connect a VCS provider in Settings → Version control.

A set covers All workspaces in this organisation or the Selected workspaces you choose, which you can search for and remove again as you go. A set's own page shows its policies and the Rego as written, the workspaces it covers, and lets you change its coverage or delete it. Deleting a set deletes its policies too, unless another set still uses them. A policy that belongs to no set is listed on the Unattached tab of Policy sets.

Advisory policies report a failure and let the run carry on. Mandatory policies stop it.

A set can be marked Allow permitted people to override mandatory failures. When a mandatory policy fails in an overridable set, the run is held: it does not apply, and its page says A mandatory policy is holding this run. Somebody allowed to override can let it continue, or the run can be discarded. When the set is not overridable, the run errors.

On the run. Each run's page has an OPA policy checks section. It names every policy set that was evaluated, each policy's result and enforcement level, and the messages your Rego returned.

On a pull request. A plan for a pull request cannot be applied, so a mandatory failure there ends the run in an error. The commit status we post goes red, and its Details link opens the run, with the failing policies and their messages in the OPA policy checks section.

Owners and admins can override a mandatory failure in an overridable set. On the held run they press Override policy failure, give a reason, and confirm. The engine records who did it and why. Members cannot: they do not see the button, and an override they send another way is refused.

There is no charge for policy sets, and the check itself is not billed. A run's plan and apply count as run-minutes as they always do; the time its policies take to evaluate does not.