Policy as Code: Run IaCM OPA policy evaluation as its own pipeline step, separate from the plan step
S
Satisfied Lark
Current behavior
In IaCM pipelines, OPA policies are evaluated as a post-plan hook (afterTerraformPlan). They run inside the same step as terraform plan / tofu plan, as soon as the plan finishes. That same step does two jobs: it generates the plan and evaluates it against every policy set in scope.
Problems
- Hard-to-read logs. Plan output and policy evaluation output share one console log. For large plans, reviewers have to scroll through thousands of plan lines to find the policy results, or the plan changes past the policy output. It's hard to review either one.
- Plan steps sized for the peak. The plan step's container needs enough CPU and memory for both plan generation and OPA evaluation of the full plan JSON. Every plan step has to be sized for that combined peak, even though the two jobs never run at the same time. For workspaces with large plans or many policies, that means raising workspace-wide resource limits, which affects every run of the workspace, not just policy evaluation.
Request
Make policy evaluation a separate step that runs after the plan step, in its own container.
- Its own step: in the pipeline graph and execution view, with its own console log, status and duration.
- Its own resources: configurable separately from the plan step, so each step can be sized for its own work.
- Same inputs as today: it consumes the plan output (plan JSON) produced by the plan step.
- Same outcome as today: a deny policy still blocks the pipeline before apply, and warnings are still reported.
- Ideally, backward compatible: an opt-in setting per pipeline or workspace, or a new step type, so existing pipelines keep working unchanged.
Business impact
- Faster, more reliable reviews. Plan and policy results can be read, linked to and shared on their own, which speeds up change review and incident investigation.
- Lower resource cost. Plan steps no longer carry OPA's memory and CPU. Resources can be sized per step instead of for the worst case.
- Clearer failures. A policy failure shows up as a failed policy step, not a failed plan step, so users and automation can tell "the plan failed" from "a policy blocked the change".
- Scales with policy adoption. As organizations add more policy sets, evaluation cost grows without making every plan step bigger.