Enforce CI/CD guardrails with OPA (Rego) policy gate

Enforce Open Policy Agent (OPA) guardrails as a CI/CD policy gate in Kestra. This blueprint uploads a Rego policy to OPA, evaluates a proposed change set (Kubernetes manifests and Terraform) against it, and fails the workflow when the policy returns any deny messages. It solves a common DevOps and platform engineering problem: stopping non-compliant infrastructure and configuration changes before they reach an environment, with policy logic written once in Rego and applied consistently across pipelines.

How it works

A single io.kestra.plugin.core.flow.WorkingDirectory task named policy_gate wraps three steps:

1. upload_policy (io.kestra.plugin.ee.opa.policy.Upload) creates or updates the ci-guardrails Rego policy in OPA. The policy denies Kubernetes Deployments with fewer than 2 replicas and Terraform that uses a public S3 bucket, and allows the change only when there are zero deny messages.
2. evaluate_policy (io.kestra.plugin.ee.opa.policy.Evaluate) sends the change set to the ci/guardrails policy path, with metrics: true and explain: "notes" for observability and debugging.
3. fail_if_denied (io.kestra.plugin.core.flow.If) inspects outputs.evaluate_policy.result.deny. If any deny messages are present, the fail task (io.kestra.plugin.core.execution.Fail) stops the run with the deny list in the error message. Otherwise the ok task (io.kestra.plugin.core.log.Log) logs that the policy passed.

What you get

• A reusable, declarative policy gate that blocks non-compliant changes.
• Centralized Rego logic that is uploaded and versioned alongside the workflow.
• Clear pass or fail outcomes, with deny reasons surfaced in the failed execution.
• Evaluation metrics and explanation output for auditing and troubleshooting.

Who it's for

• Platform and DevOps engineers building policy-as-code into delivery pipelines.
• Security and compliance teams enforcing Kubernetes and Terraform guardrails.
• SRE and infrastructure teams who want consistent, auditable approvals before deploy.

Why orchestrate this with Kestra

OPA evaluates policy but does not schedule, trigger, or wire itself into the rest of your pipeline. Kestra fills that gap: run the gate on event triggers (a webhook from your VCS or CI system, an upstream flow, or a schedule), add retries on transient OPA connection failures, and capture full execution lineage so every allow and deny is recorded and replayable. The flow is declarative YAML, so the gate lives in version control next to the Rego policy and can be reviewed like any other change.

Prerequisites

• A reachable OPA server (the policy API enabled).
• The Kestra OPA plugin (Enterprise Edition).

Secrets

• OPA_URL: base URL of the OPA server (for example http://localhost:8181).
• OPA_TOKEN: bearer token used to authenticate to OPA when it is protected.

Quick start

1. Add the OPA_URL and OPA_TOKEN secrets to your Kestra namespace or environment.
2. Adjust the Rego policy in upload_policy to match your own guardrails.
3. Replace the sample input.files in evaluate_policy with your real change set.
4. Execute the flow and confirm it fails on a denied change and passes on a clean one.

How to extend

• Feed the change set dynamically from a Git diff or CI payload instead of the static sample.
• Expand the Rego policy with more rules (image tags, resource limits, naming conventions, tags).
• Add a notification task to post deny reasons to Slack or open a ticket on failure.
• Trigger the gate from a webhook so it runs automatically on every pull request or merge.

Links

• Plugin docs: https://kestra.io/plugins/plugin-opa
• Orchestrate OPA with Kestra: https://kestra.io/orchestration/opa