Using Fugue to Check the Security of Fugue's Infrastructure as Code

Here at Fugue, we think it's important to practice what we preach. To that end, we're dogfooding Fugue! That means we use our own product to evaluate the compliance and security of our own running cloud infrastructure and infrastructure as code (IaC) with the same policies. In this blog post, we'll dive into how we set up a CI/CD pipeline that uses Fugue to scan the IaC underlying Fugue.

Why we're using Fugue on Fugue

Why did we decide to "dogfood" Fugue (or "drink our own champagne," if you prefer)?

We did this for a number of reasons:

• To visualize the IaC in our source code repository and see at a glance where noncompliance issues are. Humans are visual creatures, so seeing potential violations highlighted in red makes it easy to pinpoint areas we need to investigate.
• To be able to fix issues prior to deployment, before anything ever touches a cloud account. This allows us to "shift left," meaning we integrate security into the software development lifecycle at an earlier stage.
• To ensure the IaC on the main branch is always secure and compliant. We have the expectation that if the code is checked into main, it should pass all of our tests. Since that's the code we deploy to build Fugue, security and compliance are paramount!

An AWS S3 bucket in this example's CloudFormation template, as shown in Fugue's visualizer

What are Fugue and Regula?

Before we dive into the example, here's a quick primer on Fugue and Regula. In the Fugue SaaS, an environment represents either runtime cloud infrastructure, or an IaC repository. Each environment allows you to visualize your infrastructure and dig into its compliance and security posture.

• For environments with cloud providers, the Fugue SaaS scans the configuration of the running infrastructure.
• For repository environments, our open source CLI tool Regula scans the configuration of all IaC in a single branch and uploads the results to the Fugue SaaS.

(You can also use Regula to check IaC locally, without Fugue. In fact, that's the default behavior! You'll find a tutorial in Regula's documentation.)

How we're using Fugue on Fugue

To use Fugue to check our own IaC templates, we created a repository
environment to represent the main branch of our source code repository. We implemented a CI/CD tool to execute tests on our IaC using Regula, which uploads the test results to the repository environment

You can create a Fugue repository environment from any code repository management solution. Bitbucket, GitHub, and GitLab are some common choices. Likewise, you can use any CI/CD tool, such as Travis CI, Jenkins, or CircleCI, among others.

For the purposes of this blog post, we're demonstrating an example CI/CD pipeline that uses GitHub and CircleCI.

In this example CircleCI configuration, we've defined two types of workflows that run on the IaC we check into GitHub. One workflow runs tests whenever commits are pushed, and the other runs tests on a scheduled basis via a cron job.

• The commit workflow uses Regula to scan committed IaC locally (i.e., without uploading the results to Fugue), following these steps:
  • Developer modifies IaC and pushes a commit to GitHub.
  • CircleCI runs Regula on the IaC in the pushed branch.
  • Developer creates a pull request to merge the IaC into the main branch.
  • Developer merges the pull request, after tests pass and code is reviewed.
  • CircleCI runs Regula on the IaC in main.
• Once per day, the nightly workflow uses Regula to scan the IaC in the main branch and also uploads the results to our Fugue repository environment.

It's possible to configure the CI/CD tool such that the test results are a gating function on the deployment or PR process, as we have in this example. That means if there's a failed build — i.e., if Regula detects a security or compliance issue — the deployment does not proceed. You can, of course, configure your pipeline differently!

The example repo

To accompany this blog post, we've created an example repo containing the following files:

• cloudformation/example-cloudformation.yaml declares two example Amazon Web Services S3 buckets in a CloudFormation template.
• .circleci/config.yml defines the tests that CircleCI runs on our IaC.
• .regula.yaml specifies the Fugue environment where Regula's results will be uploaded. (The environment ID in this example is just a dummy ID.)

The CircleCI config file

Let's take a closer look at the CircleCI configuration file, so we can examine in detail how this example pipeline works.

The two CircleCI workflows we mentioned earlier (commit and nightly) involve two jobs, regula-local and regula-sync:

• The commit workflow only runs the regula-local job, which executes the regula run command on whichever branch you committed to, outputs the test results in JUnit format, and stores the results so CircleCI can display them on the Tests tab of the build log.
• The nightly workflow runs the regula-local job on the main branch and also runs regula-sync, which uploads (syncs) regula run results to Fugue to update the repository environment.

Because the regula-local job runs on every pushed commit (as part of the commit workflow), it allows developers to shift left and check the infrastructure as code on their feature branch before the code makes it to main. If the CircleCI build fails, they have the opportunity to fix the IaC before it ever touches a cloud account. Instant feedback! Plus, regula-local runs on merge commits too — which means you get the benefit of a second check after the code is on main.

Running regula-local again at night (as part of the nightly workflow) ensures that the IaC checked into main is always secure and compliant. And running regula-sync as part of the nightly workflow allows us to keep our Fugue repository environment up to date by taking a "snapshot" of what's on main once per day.

Some notes on configuration

Note that we configured the regula-sync job not to fail if noncompliant resources are found. That's because the regula-local job handles failing the build if there are any noncompliant resources. With regula-sync, our main goal is to ensure the Fugue environment is updated so we can view the report and visualization in the Fugue SaaS.

We configured the regula-sync job not to fail the build by setting the --severity off flag. If you want the build to fail when any noncompliant resources are found, just remove the --severity flag. Or, if you want the build to fail only if high-severity violations are found, set the flag to --severity high. You can set the flag to any severity level you like.

Additionally, we chose to run Regula via Docker, but you could have your CI/CD tool install the Regula binary if you prefer.

We defined the environment variable FUGUE_REGULA_VERSION so it's easy to update Regula's version. Rather than modifying the CircleCI config.yml file directly, we can just update the environment variable in CircleCI's project settings. Easy peasy!

An example run

Let's say we've just pushed a commit containing the IaC file example-cloudformation.yaml. It includes a secure bucket, MyGoodS3Bucket, and a not-so-secure bucket, MyBadS3Bucket. The not-so-secure bucket does not have all "block public access" features enabled, which is problematic! All four settings
should be enabled to help prevent the risk of a data breach.

First, GitHub triggers a CircleCI build using the commit workflow, which runs the regula-local job. Regula checks the IaC and sees that MyBadS3Bucket is not compliant with Fugue rule FG_R00229, "S3 buckets should have all block public access options enabled." So, the CircleCI build fails, and by checking the Tests tab, we can see exactly what went wrong.

Now we can fix it! If we uncomment lines 8-12 of example-cloudformation.yaml (following the remediation steps Fugue's documentation helpfully provides), we can make the bucket more secure by enabling the "block public access" features. When we push another commit, GitHub triggers another CircleCI build, which runs Regula again, and this time the test passes!

Now, if we come back the next morning, we can check CircleCI's build history to see that the nightly build passed as well, and our Fugue environment has been updated as a result of the regula-sync job.

Sounds great! How do I get started?

It takes just minutes to get up and running with a free trial of Fugue and get full visibility into the security of everything running in your cloud environment. And you’ll be able to apply Fugue’s out-of-the-box compliance rules—and your custom policies—to your infrastructure as code and running environments. To get started try Fugue free for 30 days.