This repository contains a collection of Spacelift Policy examples that can be re-purposed (if needed), and used with Spacelift. Spacelift Policies use the Open Policy Agent, which are written in the rego language. As you'll find in this repository, there are various types of Spacelift Policies - which allow for a lot of flexibility and customization. For more information on Spacelift Policies please refer to the documentation.
- Spacelift Policies: You can find information about all available Spacelift Policy types here.
- Open Policy Agent: Spacelift Policies utilize the Open Policy Agent, which uses the Rego language.
- Spacelift Policy Workbench: Use the Spacelift Policy Workbench to debug your policies using sample policy inputs.
- Testing Policies: Learn about creating test cases for your Spacelift Policies.
Policy Types Currently In This Library are below. Feel free to click on a given policy type to be taken to examples for that policy type.
| Policy Type | Description |
|---|---|
| ACCESS (Deprecated) | Define who gets to access individual Stacks and with what level of access. |
| APPROVAL | Define who can approve or reject a run/task and how a run/task can be approved. |
| LOGIN | Define who gets to login to your Spacelift account and with what level of access. |
| PLAN | Define which changes can be applied. |
| PUSH | Define how git push events are interpreted. |
| TRIGGER | Define what happens when blocking runs terminate. |
Access policies have been deprecated. Please read this for details.
- Engineering Team Access
- Downgrade access after hours
- Label Based Team Access
- Protect Administrative Stacks
- Slack Channel Access
- Who When Where Access Restrictions
- Allowlist Task Commands
- Approval needed outside working hours
- Require private worker
- Role-based Approval
- Require Approval from Security Team for certain resources
- Task and Run Approvals
- Two Approvals Two Rejections
- Two Approvals Two Rejections
- External Contributor Access:
- Managing access levels within an organization
- Readers Writers Admins Teams
- Rewriting User Teams
- Who When Where Login Restrictions
- Check blast radius
- Check sanitized value
- Checkov failed checks
- Deny on proposed runs but warn on tracked runs
- Do not delete stateful resources
- Don't Allow Resource Type
- Enforce cloud provider
- Enforce Instance Type List
- Enforce module use policy
- Enforce Password Length
- Enforce Google Cloud SQL Instance Networks
- Enforce Tags on Resources
- Enforce Terraform version list
- Ensure resource creation before deletion
- Infracost Monthly Cost Restriction
- Kics severity counter
- Mandatory and Acceptable Labels for GCP resources
- Mandatory and required labels for stacks
- Require human review for drift detection reconciliation
- Require human review for unreachable Ansible hosts
- Require human review for resource update and deletion
- Require reasonable commit size
- Trusted engineers bypass review
- Terrascan violated policies
- Tfsec high severity issues
- Warn On Change To Sensitive Resources
- Allow forks
- Cancel In Progress Runs
- Create Proposed Run From PR Label
- Deploy with Git tag
- Deploy with PR label
- Ignore Changes Outside Root
- Terragrunt Monorepo Ignore Changes Outside Root
- Lock button pauses runs by push events
- PR comment-driven actions
- PR comment-driven user specific actions
- PRs Only
- Set head commit but don't trigger run
- Tag-driven Terraform module release flow
- Track using labels
- Automated Retries
- Trigger Dependencies via Labels
- Trigger Dependencies via Labels, with state
- Trigger hardcoded dependencies
Tests can be added for policies using the convention <policy_filename>_test.rego. For example
if you have a policy called plan.rego, you can create a test file called plan_test.rego.
You can use the following command to run all policy tests:
./run_policy_tests.sh