Automating Terraform Security in Scalr Deployments with Regula

Introduction to Regula and Scalr Integration

Regula

Regula enables cloud teams to evaluate Terraform, CloudFormation, Azure Resource Manager, and Kubernetes Infrastructure-as-Code (IaC) for security and compliance violations prior to deployment. Regula is an open source implementation of Rego, the query language used by the Open Policy Agent (OPA) project. Where relevant, Regula's policies have been mapped to the Center for Internet Security (CIS) Amazon Web Services (AWS), Azure, Google Cloud, and Kubernetes Foundation Benchmarks to allow users to enforce these policies on IaC prior to deployment.

Because Regula catches misconfigurations before deployment, security and compliance checks move into the hands of the developers writing the code. That removes the bottleneck of waiting on a security review after the fact. Regula is maintained by Fugue engineers.

Scalr

Scalr is a Terraform Automation and Collaboration (TACO) software that has support for pull request automation, native Terraform CLI, or module-driven workflows. Scalr helps organizations of all sizes scale through its hierarchical model that centralizes admin operations like RBAC, policy control through OPA, operational views, and a private module registry, resulting in controlled decentralization of Terraform operations allowing developers to execute Terraform workflows within environments independently.

Goal

This post pairs Regula's IaC scanning with Scalr's Terraform automation to show how a team can deploy cloud infrastructure securely without slowing down.

Prerequisites

If you want to follow along, you'll need the following:

• A Scalr account with custom hooks enabled. See below for how to configure these.
• A workspace configured in your Scalr account. A workspace is where all objects related to Terraform-managed resources are stored and managed.
• Cloud provider credentials added to your Scalr account (for this demonstration, I will be using AWS)
• A version control system (VCS) provider configured in your Scalr account (for this demonstration, I will be using GitHub)
• Assign scripts/security.bash as the "Before plan" custom hook and scripts/validate.bash as the "After plan" custom hook
• The latest version of Regula in your /usr/local/bin directory (our security.bash script will pull this and run it within the Scalr pipeline, but having it locally will allow you to evaluate your code prior to committing)
• (Optional, and requires a Fugue account) Generate Fugue API ID and Fugue API Secret and set as workspace variables in Scalr

Optionally, you can also clone my repository to save yourself some work by executing the following command in your Terminal:

git clone https://github.com/fugue/fugue-scalr-integration.git

What's in the repo?

The screenshot above shows the file structure of my repository. The parts that matter here:

• main.tf: A Terraform file that declares provider and module information
• s3/: A subdirectory that holds Terraform files that contain intentional vulnerabilities
• waivers.rego: A file that waives and disables select rules
• .regula.yaml: A Regula configuration file that declares how I want Regula to be run in this repository
• scripts/: A subdirectory that contains the custom hook described above

Here is a better view of the contents of the S3 module, along with an overlay of the configuration status of all infrastructure (violations of CIS Benchmarks are in red):

Configuring Scalr custom hooks

Custom hooks are used to customize the core Terraform workflow, whether with commands, scripts, or API calls. In addition to using Regula for security and compliance scanning, the shell scripts used in this demonstration include checks on Terraform formatting and validation.

Custom hooks can be added upon creation of a workspace or anytime thereafter by going into the workspace settings and specifying what should be run before and after plan; and before and after apply. See below for a demonstration of how to set up custom hooks:

Within the "Advanced" options in the "Settings" page, Scalr enables users to choose the relative path in which Terraform commands will execute (I selected the s3/ directory for this example), which is why the path to the scripts is preceded by "./../".

Automating security scans along the path of least resistance

When you need infrastructure fast, the easiest move is to grab Terraform code off the internet or from a colleague and assume it's secure. Beginners and experienced engineers both do it. That code often passes every formatting, linting, and validation check you throw at it while still carrying serious vulnerabilities.

Exposing latent vulnerabilities: scanning infrastructure with Regula

For this demonstration, I deliberately took that shortcut and looked for Terraform code that would deploy an S3 bucket as fast as possible. To show how vulnerable that code is, I'll run regula run against the repository locally:

When you execute this command, Regula will:

• automatically detect supported IaC files throughout the entire repository
• run a security and compliance scan against all detected, supported IaC files
• Output the results of that scan in descending order of severity, with the following information:
• Fugue rule ID (e.g. FG_R00099) and title
• Rule severity (e.g. [High])
• Hyperlink to rule remediation steps (e.g. https://docs.fugue.co/FG_R00099.html)
• Location of rule violation listed by IaC file

These results should worry DevOps and security engineers alike. Copy, paste, and deploy vulnerable code, and you expose yourself to attackers who use automation to find and exploit exactly these gaps. And notice that I ran this scan by hand, outside any pipeline (Scalr's included), which is more effort than the shortcut I took to get here. Past breaches show the pattern: attackers scan for misconfigurations like an open S3 bucket, then use them as a foothold to reach the data that matters most. If you aren't using the same kind of automation to catch those problems before they reach the cloud, a breach becomes a question of when, not if.

Let's look closer at one of these violations with a snippet of the code (if you're following along, the code below is from lines 18 - 26 of s3/bucket.tf, and the indentation is adjusted left for easier viewing):

server_side_encryption_configuration {
  rule {
    apply_server_side_encryption_by_default {
      #Un-comment below to satisfy FG_R00099
      #kms_master_key_id = aws_kms_key.mykey.arn
      #sse_algorithm     = "aws:kms"
    }
  }
}

I've paired each intentional vulnerability with a comment showing where to revise the code so it satisfies the numbered rules that ship with Regula. As written, the code above violates rule FG_R00099 (a high severity violation according to CIS Benchmarks): if deployed as-is, this AWS Simple Storage Service (S3) bucket would expose data at rest. If you're new to this, picture leaving a bank vault and a safety deposit box wide open. You can move the deposit in an armored truck (transit encryption in this analogy), but if the vault stays unlocked (server side encryption never applied), the data is still exposed.

The unsettling part is where I got this code. The Terraform documentation I copied it from shows how to deploy an S3 bucket in the simplest possible way, the way documentation usually does. It leads with the required parameters and pushes optional ones, server side encryption included, into the later sections most people skim past. Configuring your cloud resources securely is on you. The cloud provider just hands you the building blocks.

Why leave security up to chance when you can so easily automate it?

Applied flexibility: waiving and disabling rules

Sometimes a real business need conflicts with a low or medium severity rule. Take a company that serves content from an S3 bucket hosting a static website. That bucket has to be public, so flagging it for violating FG_R00229 (S3 buckets should have all "block public access" options enabled) gets old fast. Regula lets you waive a specific rule for a specific resource, or disable a rule entirely. For this demonstration, I waive FG_R00274 for my logging bucket and disable Fugue rule FG_R00275 outright, both through my waivers document (waivers.rego). Here is how waiving and disabling rules looks:

package fugue.regula.config
 
waivers[waiver] {
  waiver := {
    #Waiving bucket logging (for the logging bucket)
    "rule_id": "FG_R00274",
    "resource_id": "module.s3.aws_s3_bucket.logbucket"
  }
}
 
rules[rule] {
  rule := {
    #Disabling cross region replication (budgetary purposes)
    "rule_id": "FG_R00275",
    "status": "DISABLED"
  }
}

Operationalizing IaC security: stopping misconfigurations from getting to the cloud

Now for the part that ties it together: how Regula works with Scalr's remote state and operations backend to keep misconfigured infrastructure from ever reaching the cloud.

The first custom hook script (security.bash) pulls, extracts, moves, and executes the latest version of Regula, scans all Terraform files (HashiCorp language (HCL) or Terraform JavaScript Object Notation (JSON) plans), and produces either a non-zero exit code and message that stops the Scalr build from continuing; or an exit code of zero, allowing the Scalr build to continue.

The next custom hook script (validate.bash) ensures that the Terraform in this repository is valid and properly formatted according to HCL canonical standards. If the Terraform is not valid, this script produces a non-zero exit code. If the Terraform is valid, Scalr executes the rest of the build, automatically running terraform plan and terraform apply, thus deploying your infrastructure to the cloud and maintaining the Terraform state in its easy-to-use interface.

Trying (and failing) a build

Next, I will show you what it looks like when I commit vulnerable Terraform code to my GitHub repository. I begin by executing the following commands ( is a placeholder for which files should be committed and pushed to GitHub):

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

Scalr will detect that I have committed changes to my repository, and will use the scripts I have provided to scan my Terraform for security and compliance issues:

Resolving configuration issues with Regula

Now that I know my Terraform files have misconfigurations, I can open the repository in VSCode and run regula run locally to work through them (or I could export the output from the regula run that already happened in my Scalr run). I built this repository so I can un-comment the corrections quickly, but in practice fixing the infrastructure is mostly a matter of clicking the link Regula prints next to each rule. Both rules I'm fixing (FG_R00036 and FG_R00101) are single lines of code, pulled straight from the remediation steps behind that link.

Trying (and succeeding!) a build

With my infrastructure properly configured, I'll commit to my GitHub repository again to maximize Scalr's Terraform automation capability. This will again run my custom hook scripts, then (if those are successful) Scalr will run terraform plan and terraform apply.

To demonstrate this, I'll re-run the commands I ran initially:

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

...resulting in a successful build!

And that's it. Regula and Scalr now give us a pipeline that deploys cloud infrastructure with Terraform and checks its security on the way out.

Next steps

The example above shows how to secure your IaC according to CIS Benchmarks, but for those who need other compliance families (such as HIPAA, SOC2, ISO 27001, NIST 800-53, GDPR, PCI DSS, AWS WAF, or CSA), please visit www.fugue.co. The example above also shows custom hooks, but for those who desire more quality of life features such as cloud infrastructure cost estimation, self-hosted agents, SSO, or policy previews, please visit https://www.scalr.com/.

Want to learn more about Regula? See our GitHub repo and documentation. Regula evaluates Terraform HCL, Terraform plan JSON, CloudFormation YAML/JSON, Kubernetes YAML manifests, and Azure Resource Manager templates for security and compliance. Regula also supports waivers, custom rules, enabling or disabling rules, and more.

Interested in other ways to automate the secure deployment of cloud infrastructure? Check out our blog post about integrating Regula and Travis CI, or our blog post about integrating Regula and Bitbucket Pipelines.

You can also use Regula with Fugue to achieve end-to-end security and compliance across the entire software development lifecycle – from development to deployment to runtime. For more information about Fugue, visit www.fugue.co.