Enforcing Open Policy Agent guardrails across your cloud configurations
Open Policy Agent (OPA) provides a valuable set of standards to dictate how DevOps, IT, and platform teams should configure cloud infrastructure.
Enforcing standards based on OPA, however, is often easier said than done.
Many DevOps teams are limited to the traditional, manual ticketing and reviewing processes—and understandably so. To ensure that all configurations comply with the organization’s standards, those who set and understand the standards need to review and validate the configurations.
Naturally, this leads to bottlenecks that delay application release timelines and lead to shadow IT. As a result, the skilled infrastructure experts who can orchestrate and maintain these environments end up inundated with requests that take time away from more valuable projects.
To alleviate this bottleneck, we help our users automate the enforcement of guardrails based on OPA across all cloud configurations, including restricting deployments that violate those standards and notifications to administrators in the event of those violations.
This cuts out the manual ticketing process so DevOps teams can deliver infrastructure and environments faster while still ensuring configurations are up to date with the latest requirements.
Here’s how we help our users accomplish this:
Step 1. Distribute role-based access to pre-configured infrastructure and environments
Using Quali’s Torque platform, DevOps teams give developers and other end users self-service access to view and launch the pre-configured infrastructure and applications they need.
This starts by importing the IaC configurations, Helm Charts, and native Kubernetes assets from their Git repositories into a repeatable file—referred to as a blueprint—that defines the complete environment.
Once environments are made repeatable, end users can browse a catalog, view the underlying infrastructure within each environment, and launch them on demand. Role-based permissions prevent end users from making any unauthorized modifications to the configurations, while optional approvals trigger notifications to allow administrators to allow or prevent a deployment before it happens.
However, with this increased flexibility comes the need for proper governance and control. To address this, Torque has introduced “Torque policies” powered by Open Policy Agent (OPA).
Step 2. Select the built-in OPA policies for your configurations
In Torque, OPA acts as a decision engine to enforce policies on environments. Torque leverages OPA to manage consumption and security policies and triggers these policies during various stages of the environment deployment pipeline, such as when launching a new environment, extending its duration, or deploying environments using Terraform.
Torque comes with several out-of-the-box policies to support some of the more common use cases when deploying environments in the cloud. Some examples include:
- Allowing only specific AWS instance types
- Deploying only to specific Azure locations
- Setting a maximum cost limit for environments
These policies can be assigned to the entire account or specific teams, and their specific data can be configured accordingly.
Step 3. Customizing policies for cloud configurations
In certain scenarios, you may need to go beyond the common use case and create your own policies and rules.
Custom policies are written in rego files and reside in your Git repository. Once you introduce a rego file, Torque will automatically discover it, identify it as a policy, and allow you to import it.
Just like built-in policies, custom policies can be applied to the entire account or specific teams and can be configured with relevant data. As these policies reside in your Git repository, they can be managed in GitOps mode, similar to your application or Infrastructure as Code (IaC) code. When you want to introduce a new version of your policy, you can develop and test it in your Git flow and update the commit version in Torque.
Example OPA Policy in Torque
Suppose you want to enforce a policy that allows Terraform to provision resources only in the us-east-1 region for team A and only in eu-west-1 region for team B.
To achieve this, you first create the following custom policy as a rego file and import it to Torque:
This policy checks the provider name and region fields in the input and evaluates the deny rule to be satisfied if the region used is not included in the configured allowed regions. Note that the string “us-east-1” or “eu-west-1” are not hard-coded into the rego file.
In Torque, you will have two copies of the policy from the same rego file: one for team A with “us-east-1” as the data.allowed_regions, and one for team B with “eu-west-1” as the allowed_region.
Quali’s Torque platform is designed to help our customers balance speed and control for their infrastructure processes.
By using OPA to enforce policies on environments, the platform ensures proper governance and control while allowing end-users the flexibility to provision environments on their own.
At scale, this means DevOps teams can spend less time manually orchestrating and reviewing application environments while also enhancing overall governance and compliance across their cloud configurations.