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.
This week, Fugue announced support for AWS CloudFormation in Regula, the open-source policy engine for infrastructure as code (IaC). Regula has been gaining in popularity for performing pre-deployment security and compliance checks for Terraform, and we’re thrilled to extend Regula’s capabilities to address CloudFormation templates, including the Serverless Application Framework.
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.
Today we announced that Fugue now supports Google Cloud, in addition to Amazon Web Services (AWS) and Microsoft Azure. Google Cloud support is key to providing our customers with a unified view of—and control over—the security posture of their cloud environment across cloud platforms. It was a top customer request, and considering the number of Google Cloud Projects we’ve seen onboarded to Fugue over the past few days, it’s clear that Google Cloud is experiencing significant growth.
Today, Sonatype and Fugue have partnered to deliver the tools developers and operations need to address every meaningful cloud attack surface and ensure compliance at every stage of the SDLC with a single unified solution. Read the press release here.
Azure offers two similar but distinct services to allow virtual network (VNet) resources to privately connect to other Azure services. Azure VNet Service Endpoints and Azure Private Endpoints (powered by Azure Private Link) both promote network security by allowing VNet traffic to communicate with service resources without going over the internet, but there are some differences. This three-part blog series goes into detail about both services.
This is a companion post to our Cloud Security Masterclass on the subject. Our objective is to examine some real world, published cloud exploits and examine both the motivations and techniques of the hackers responsible for them so that you can understand who you are up against, how and why they act, and how to better protect your cloud infrastructure.
Azure offers two similar but distinct services to allow virtual network (VNet) resources to privately connect to other Azure services. Azure VNet Service Endpoints and Azure Private Endpoints (powered by Azure Private Link) both promote network security by allowing VNet traffic to communicate with service resources without going over the internet, but there are some differences. This three-part blog series goes into detail about both services.
At Fugue, we’re pretty fond of Open Policy Agent (OPA), and we’ve written a lot of Rego code to keep cloud resources secure. So we’ve put together the most valuable lessons we’ve learned in the process.
