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.
commitworkflow 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
- Developer merges the pull request, after tests pass and code is reviewed.
- CircleCI runs Regula on the IaC in
- Once per day, the
nightlyworkflow uses Regula to scan the IaC in the
mainbranch 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.yamldeclares two example Amazon Web Services S3 buckets in a CloudFormation template.
.circleci/config.ymldefines the tests that CircleCI runs on our IaC.
.regula.yamlspecifies 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.
commitworkflow only runs the
regula-localjob, which executes the
regula runcommand 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.
nightlyworkflow runs the
regula-localjob on the
mainbranch and also runs
regula-sync, which uploads (syncs)
regula runresults to Fugue to update the repository environment.
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
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.
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
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.