Manage policies

Admin guide

The policy set is the rules Greenlight evaluates on every pull request, at the policy check, to decide whether a commit may deploy. As an Admin or Org Owner you control which rules are active, whether each one blocks or merely warns, how each is configured, which catalog templates and compliance packs are enabled, and any custom rules your org writes. This page walks the day-to-day workflow. The concepts behind it — what the policy set is and how OPA evaluates it — are in Governance & policy.

Every organization starts with a seeded default bundle, so there is nothing to set up before your first app. Everything below is optional and incremental.

Open the Policies surface

Policy management lives in Settings → Policies. Admins and Org Owners see it; Builders do not — policies are org-wide governance.

The page lists every rule in your set — default, catalog-enabled, and custom. Each row shows the rule’s name and description, its origin, whether it is set to block or warn, whether it is active, and who last changed it. A rule you have customized away from its seeded or template default is marked as such.

Set enforcement: block or warn

Each rule is either block or warn:

• Block — a violation fails the policy check and the commit does not deploy. This is the default for security-critical rules (no hardcoded secrets, approved base images, parameterized queries).
• Warn — a violation surfaces in the check detail and the audit log but does not stop the deploy. Use warn while you roll a new rule out, or for advisory rules you want visibility on without gating.

Change a rule’s enforcement from its row. The change is audited and takes effect on the next pull request.

Enable or disable a rule

Disabling a rule (toggling it inactive) takes it out of evaluation entirely — it neither blocks nor warns. Re-enabling restores it with its configuration intact. Prefer warn over disable when you still want visibility; disable only when a rule genuinely doesn’t apply to your org.

Edit a rule’s configuration

Most rules carry configuration — the specifics they enforce. The form adapts to the rule you’re editing:

Rule	What you configure
Approved base images	The list of allowed Docker base images (e.g. node:20-alpine, python:3.12-slim).
Approved dependencies	A package denylist and optional allowlist, plus a CVE allowlist with a reason and expiry per exception.
Resource limits	The minimum CPU and memory a pod must declare.
No eval / parameterized queries	Files exempted from the rule.
No hardcoded hosts	Hostnames the rule permits.

1. Open the rule. Click its row to expand the configuration form.
2. Edit the fields. The form shows only the fields that rule supports.
3. Save. Greenlight validates the configuration before storing it — an invalid value is rejected with an explanation and never reaches the evaluator. A valid change is audited and effective for the next pull request.

Note

For default and catalog rules, configuration is structured data validated on write — you are filling in a form, not writing policy code. The underlying rules are maintained by Greenlight. Authoring policy code is the custom-rule path below.

Enable a catalog template or pack

Beyond the seeded defaults, Greenlight ships a catalog of curated rule templates grouped into packs (for example, a SOC 2, HIPAA, or GDPR pack). Enabling a template adds its rule to your set without writing any code.

1. Open the catalog. From the Policies surface, browse templates individually or by pack.
2. Enable what you need. Enabling a pack turns on its templates together; you can also enable a single template.
3. Configure and save. Fill in the template’s fields (the same form-based configuration as above). The new rule joins your set, audited and effective for the next PR.

Write a custom rule

When the catalog doesn’t cover an org-specific policy, an Admin or Org Owner can author a custom rule in OPA’s Rego language, evaluated against Greenlight’s evidence schema — the same scanner findings, manifest, repo facts, and grant state the built-in rules see. The editor documents the fields available so you write against a stable contract.

1. Open the custom-rule editor and give the rule an id and description.
2. Write the Rego. The editor validates as you type; a syntax error or a reference to a field outside the evidence schema is flagged before you can save, and a rule id that collides with a built-in is rejected.
3. Dry-run the preview. Greenlight compiles the rule and evaluates it against sample evidence so you can see exactly what it would allow or block — before it touches a real pull request.
4. Save. The rule is created in warn mode (shadow): it reports in the check detail and audit log but does not block any deploy yet.
5. Promote to block. Once you’ve watched it behave as intended on real and sample inputs, switch its enforcement to block — the same control as any other rule.

Tip

Warn-first is deliberate. A brand-new rule that gates every deploy is risky; shadow mode lets you confirm it does what you mean before it can stop a merge.

What’s audited

Every enforcement change, enable/disable, and configuration edit writes an audit event capturing the actor, the rule, and the change. The audit log is the source of truth for “when did this policy change, and who changed it” — the question a compliance review eventually asks. Override frequency at the policy check surfaces alongside, so you can see when a rule is being routinely bypassed and decide whether it needs to change.

Next

Governance & policy The roles, the policy bundle, the kill switch, and override audit.

Source control & the policy check What the check evaluates and how failures surface to agents.