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.
Regula 2.3.0 enables cloud teams to evaluate Terraform, CloudFormation, Azure Resource Manager, and Kubernetes infrastructure as code (IaC) for security and compliance violations prior to deployment. Integrating Regula into continuous integration/continuous delivery (CI/CD) pipelines takes this a step further by automating the secure deployment of cloud infrastructure.
This week, Fugue announced unified infrastructure as code (IaC) and cloud runtime security. For the first time, cloud engineering and security teams can automate security across the development lifecycle using the same policies.
Cloud security has long been focused squarely on the cloud runtime environment to keep infrastructure free of misconfiguration vulnerabilities that can open the door to hackers and lead to data leaks and breaches. It is reasonable considering most (if not all) cloud-based security incidents result from customer mistakes in the form of cloud resource misconfiguration. Gartner calls this Cloud Security Posture Management, or CSPM.
Regula 1.0 makes it easy to check Terraform and CloudFormation infrastructure as code (IaC) for security vulnerabilities and compliance violations, especially in continuous integration/continuous delivery (CI/CD) pipelines (read about the Regula 1.0 launch in Help Net Security and on our blog here).
Regula, our open-source infrastructure as code (IaC) policy engine, now supports AWS CloudFormation. This means you can use Regula to perform static analysis of CloudFormation YAML or JSON templates for security vulnerabilities and compliance violations – including templates that use the Serverless Application Model. For instance, if a template declares an EBS volume that does not have encryption enabled, Regula’s report will show which template – and which specific resource – failed the check.
In this blog post, we’ll talk a bit about how Rego evaluation works, and how it affects performance. Rego is a DSL for authoring policy. It is not restricted to a single kind of policy (e.g., RBAC) but instead is very general-purpose, making it possible to share policies across different services and stacks. We’ve found Rego to be ideal for cloud infrastructure security in Fugue, and infrastructure as code security in our open source project, Regula.
Recently, I was tasked with creating an automated testing tool for Fugue. Fugue monitors cloud resources for compliance and security, and we needed a way to verify that the full results of a Fugue scan were correct. My goal was to create an automated system that runs locally or in CI, deploys configurable infrastructure, scans it using Fugue, and verifies the results. This blog post walks through the design and implementation process for what became autotest, our internal automated testing tool.
In part 1 of this walkthrough, we set up a CI/CD pipeline to define, commit, deploy, and secure infrastructure as code. To recap, here are the components:
Fugue allows you to easily and programmatically validate your cloud infrastructure for security and compliance. By integrating Fugue into your CI/CD pipeline, you can detect resource misconfiguration and compliance violations as part of every deployment.