how/cicd

Policy gate: blocking violations between plan and apply

An engine sits between the plan and apply steps: Checkov, OPA, or Sentinel. It reads plan.json and decides whether the change can be applied. A bucket with no encryption simply will not pass.

terraform plan already told you what will change. The reviewer from the [[tf-plan-as-artifact|PR comment]] already looked at it and approved the change. terraform apply will run with [[tf-oidc-aws|narrow temporary creds]]. What could go wrong?

A person can fail to notice that a new S3 bucket is created with no encryption. Or that a security group is open to 0.0.0.0/0 on port 22. Or that an IAM policy grants Action: "*". All of this is visible in the plan, but a plain text plan runs 200 lines and the eye glazes over.

A policy gate solves this automatically: between plan and apply sits an engine that reads plan.json and checks the changes against formal rules. A violation means apply is blocked.

Press ▶ to see how this works.

step 1/6·00 · no gate: plan → apply

§ steps

A standard pipeline: terraform plan → the reviewer nods → terraform apply. Nothing formally checks that the plan has no compliance violations.

In a small team with disciplined engineers this works. In a large team or under deadline pressure, sooner or later an S3 bucket with public access, an RDS with no encryption, or a security group open to 0.0.0.0/0 slips through.

The gate solves this problem with automation.

recap

What to remember:

The gate works with plan.json, not with HCL. plan.json holds all computed values, including what shows up only during the refresh. Reading HCL with your eyes does not give you that.
Three popular engines:
Checkov: rules ready out of the box (CKV_AWS_, CKV_AZURE_), integrates in 10 minutes. For a compliance baseline, it is the fastest start.
OPA / conftest: you write the rules yourself in Rego, nothing preinstalled. For team specifics (for example, "every bucket must use our KMS key").
Sentinel: native to Terraform Cloud / Enterprise. Not open source. If you are not on TFE, it is usually OPA or Checkov.
The gate does not replace the reviewer. The engine catches formal violations; a human catches "we are digging in the wrong direction". You need both.
Rules are written gradually. Start with one or two critical ones (S3 with no encryption, a security group open to 0.0.0.0/0 on SSH), and expand as incidents appear.
You can make the engine soft: it prints a warning but does not block apply. Good for onboarding, bad for prod. The default is a hard fail.

With this stack the whole CI/CD side is covered: the [[tf-plan-as-artifact|plan artifact]] + [[tf-oidc-aws|OIDC creds]] + a policy gate = a production-ready pipeline for Terraform.

§ dig into the knowledge base

§ try it hands-on

§ steps

A standard pipeline: terraform plan → the reviewer nods → terraform apply. Nothing formally checks that the plan has no compliance violations.

In a small team with disciplined engineers this works. In a large team or under deadline pressure, sooner or later an S3 bucket with public access, an RDS with no encryption, or a security group open to 0.0.0.0/0 slips through.

The gate solves this problem with automation.