Security, audit and limits
Who can change release policies, enforce and observe modes, the audit trail, and the limits Prodgator applies.
Security considerations
A release policy is code that can approve a deployment to a protected environment. Treat it with the same care as your deployment workflows.
Who can change policies
- Policies in the editor. Only organization members with the role can create, edit, import, bind, unbind or archive a policy. Other roles can view policies and their bindings.
- Policies in a repository. Anyone who can push to the repository's default branch can change . That includes adding an enforce policy that approves every deployment to that repository's environments, or removing one that holds them. Prodgator applies whatever the default branch holds; it does not review the change.
Protect the folder the way you protect :
- Turn on branch protection (or a ruleset) for the default branch and require pull request reviews.
- Add a entry, for example , and require review from code owners.
- Block force pushes and branch deletion on the default branch.
- Keep the Prodgator GitHub App installed only on repositories that should hold policies.
Enforce and observe
An enforce policy answers GitHub: its decision can approve or reject a deployment. An observe policy only records its decision on the deployment. Start a new policy in observe mode, compare its decisions with what happened, then switch it to enforce.
A policy bound to an environment governs every deployment to it. Check a binding's repository and environment patterns before you save them; and match more than you might expect.
Audit trail
Every change leaves a record:
- The audit log records who created, saved, imported, archived, bound or unbound a policy, each repository sync that applied or failed, every evaluation, and every break-glass use.
- Each saved version is kept, so you can see what a policy said when it decided a deployment.
- Each evaluation stores the exact input the policies saw, and the comment on GitHub names the policies, their versions and each rule's result.
Limits
These limits keep one policy from slowing down or blocking others. Prodgator checks them when you save a policy and again on the server.
| Limit | Value |
|---|---|
| Rego per policy (custom rules, Rego files and tests together) | 200 KB, counted in UTF-8 bytes |
| Form rules per policy | 50 |
| Custom Rego rules per policy | 25 |
| Rego files per policy, and test files per policy | 20 each |
| Active policies per organization (editor and repository together) | 100 |
| Policies governing one deployment | 20 |
| Policy files read per repository | 50, up to 128 KB each |
| Time to evaluate one policy | 2 seconds |
| Memory for one policy evaluation | 64 MB |
| Time for one compile step (check, test or build) | 25 seconds |
| Time for a policy's tests | 5 seconds |
When more than 20 policies govern one deployment, Prodgator evaluates none of them and the deployment waits; remove bindings until 20 or fewer apply. Adding a binding is refused when 20 policies already have the same target.
The input document caps its lists: at most 100 , 100 and 100 , and 4,096 characters of and , and 100 . An attestation whose is longer than 8,192 characters as JSON keeps only its top-level numbers, strings and booleans, plus . When a list is cut, rejections, failing checks and attestations that do not pass are kept first, so a cut list holds a deployment rather than approving it. Nested loops over the same list still add up: three nested loops over 100 approvals take about 0.3 seconds, and the time grows with the cube of the list size.
Audit log
Prodgator writes an audit event when a policy is created, saved, imported, archived, bound or unbound, when an approver group changes, when a repository sync applies or fails, and for every evaluation.
How the compiler and the policy runtime are isolated is on Write a policy in Rego.