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 the 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 a 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.
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).
Scalr 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:
Each OPA policy can have a different enforcement level:
Terraform, OPA, and Scalr 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…
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:
Both parties will be saved from the annoyance of scrambling to fix something after the fact.
Scalr 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