This post originally appeared on the Scalr blog
Infrastructure as code, especially Terraform, has taken off over the past years allowing developers to declaratively deploy cloud resources. The universal language makes it easy for DevOps to learn a single language to enable management of infrastructure anywhere. This is great for DevOps teams but not always great in the minds of the security team. What if there was a similar way to write policy to check your Terraform templates prior to deployment? The security team will be happy and you’ll have cleaner code… enter Open Policy Agent (OPA).
What Terraform did for infrastructure automation, OPA is doing for policy automation. OPA is also a universal declarative language, that enables policy definition across all clouds and many other non-cloud platforms and systems. The Kubernetes world is no stranger to Open Policy Agent, but now we are seeing the adoption growing for Terraform and many other platforms in the cloud ecosystem.
Example: An OPA policy restricting which instance types can be used.
Security is one of the most important aspects of scaling cloud adoption, but improperly done, it can make a DevOps workflow inefficient. You want to ensure that your users can provision resources as needed and avoid a painful ticketing or review process that could slow down a deployment process, thus defeating the purpose of automation. Adding policy to a pipeline ensures your users are able to provision resources within a defined set of guardrails reducing security, financial, and operational risk.
So now we have Terraform and OPA, but how do we ensure that the OPA code is actually used in our pipelines? Enter the Scalr Infrastructure as Code Platform (IaCP).
OPA in Scalr
The Scalr IaCP is a Terraform remote operations backend that uses and enforces OPA at various levels on all runs that come through the pipeline. Scalr utilizes customer written OPA policies pulled from a Version Control System (VCS) to check all Terraform runs.
Scalr allows for different pipelines, environments, and accounts to follow different policies based on customer or business need. A few examples of commonly created policies are:
- Naming Conventions – Enforce workspace, instance name, and tagging standards.
- Limits – Networks, images, locations, cloud resources, and more.
- Cost – Allow auto approval for cost under a certain level, but force approval for those over that level.
- Module Enforcement – Ensure users are only using modules that are approved.
- And many more..
Each OPA policy can have a different enforcement level:
- Advisory – A notification that a violation happened.
- Soft-Mandatory – The Terraform run will go into an approval state based on a violation.
- Hard-Mandatory – The Terraform run will be rejected based on a violation.
Example: Dry run report on pull requests to linked policies and the impact it has on existing workspaces
Terraform, OPA, and the Scalr IaCP gives you an automated workflow that ensures the DevOps teams are deploying their resources in a secure manner. But let’s not forget about existing resources, standards and policy change, but that doesn’t mean we need to break our existing deployments…
Existing Deployments
It is not uncommon to update your compliance or security guidelines over time. So how do you ensure your existing deployments are accounted for?
Scalr has implemented OPA dry runs for this exact use case. A policy dry run will help you predict how impactful policy changes are in your environment by running them against existing Terraform deployments and reporting how many of those deployments violate the policy prior to it being implemented.
When a pull request to make a change is opened on the policy, Scalr will automatically evaluate all new and existing deployments, but not affect any workspaces until the policy changes are merged to master. Even then, the existing workspaces will not be altered, only new runs of the existing workspaces will be checked against policy. The result of the dry run evaluation will be a report that serves two purposes:
- The administrator will be able to recognize how impactful the new policy is or if a mistake was made.
- The DevOps teams will have time to make changes to their deployments prior to the policy being merged.
Both parties will be saved from the annoyance of scrambling to fix something after the fact.
Example: Dry run report on pull requests to linked policies and the impact it has on existing workspaces
Summary
The Scalr IaCP and OPA will help you ensure that all deployments are done in an efficient and automated manner while not compromising on security. The GitOps and “as code” approach is growing throughout the industry, following this approach with your Terraform deployments and policy will help drive adoption with your DevOps and SecOps teams. Equally important, a single language across the cloud ecosystem, whether it is for infrastructure or policy, will increase the efficiency of your DevOps teams.
Give it a try
Learn more here
Top comments (0)