In the past few months, we’ve talked with hundreds of developers, DevOps leads, CISOs, and everyone in between about infrastructure-as-code (IaC). Across those conversations, we’ve pinpointed three foundational motivations for adopting IaC—the need for mobility between cloud providers, predictability, and improved governance controls.
That last point is where our ears perk up.
At Bridgecrew we recognized the part IaC plays in securing cloud-native environments early on. To us, infrastructure-as-code security is a great (if not the best) way for modern teams to delegate security ownership to individual contributors while distributing it across existing frameworks within CI/CD pipelines.
Because we know it's potential and we've seen how widely the understanding of IaC varies, we decided to spend some time writing about it—its rise, where security fits into it, and what you need to do it successfully.
First, a definition courtesy of Wikipedia:
“Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.”
In more modern, cloud-native terms, IaC makes it easier and more foolproof for teams to configure cloud resources at scale.
The rise of infrastructure-as-code
According to the same Wikipedia article, IaC was born in 2006, the same year that AWS’ Elastic Compute Cloud and Ruby of Rails 1.0 were launched—but that reference links to a gated Gartner report. 🤔
This Who Tweeted it First query is a bit more interesting.
Regardless of the exact moment the term IaC was coined, interest in it has steadily grown in the past decade for teams needing to reliably orchestrate resources at scale. It wasn't until Terraform came onto the scene in 2014, however, that IaC really had its moment.
More than any other framework, Terraform has popularized infrastructure as code with its open-sourced modules and has paved the way for the future of the IaC ecosystem. The earliest website snapshot I could find on the Wayback Machine from terraform.io in 2014 does a great job explaining what infrastructure-as-code should do.
Elsewhere on that first site, they explain how Terraform differs from configuration management tools (Chef, Puppet, etc.) and is inspired by cloud provider tooling (CloudFormation, Heat, etc.) to solve the same problems in a cloud-agnostic environment. It does not, however, make any mention of testing or security.
Where security fits into infrastructure-as-code
Fast forward to the end of last year.
We at Bridgecrew have made major headway building out our cloud security posture solution and have been focusing on automating the identification and remediation of public cloud security issues for our early customers. But we keep running into the same problems time and time again.
More and more of our customers have adopted IaC—for many of the reasons we cited earlier. But very few have processes and tools in place to secure it. Although they’re aware that even the smallest misconfiguration can unknowingly leave infrastructure exposed, they just don’t know where to start.
At the same time, we start seeing that when cloud misconfigs are fixed in run-time—for example, changing a publicly exposed S3 bucket to private—it's highly likely (about a 70% chance) that it'll resurface in the near future. The problem is that when clouds are orchestrated by inherently misconfigured code, they’ll continue to be configured incorrectly in production.
So, what’s the solution?
The 3 keys to infrastructure-as-code security success
When done right, infrastructure-as-code security addresses both misconfigured IaC files during development and transforms run-time security issues into build-time governance. But for infrastructure-as-code security to be valuable and successful, it must be 1) automated, 2) delivered-as-code, and 3) part of a continuous workflow.
Automated IaC governance
Infrastructure misconfigurations may (sometimes) be trivial, but finding them manually is not. Expecting all developers to be up-to-date with hundreds of policies across cloud providers is unrealistic. Additionally, because the discipline is so new, it can be difficult to find helpful resources. By automating the scanning of IaC, you save time and get a level of coverage not otherwise possible.
Governed in code, secured in code
Finding the right tooling to automate the identification of IaC issues is imperative, and if you can apply that same methodology to fixing them, even better. To do that, fixes need to be delivered in a common language—code. By implementing infrastructure security as code, you not only equip developers with the actual solutions to their problems, but you set policies to govern your infrastructure going forward. That right there is the whole point of IaC.
Continuous workflow
Finally, infrastructure-as-code security needs to be embedded into the tools and day-to-day processes you already depend on, or it’ll never get adopted. Whether you’re adding it to your pull request checks or a failing step in your CI/CD pipeline, it should be part of each and every code review. Not only will that enable you to identify newly defined policy violations, but will harden your IaC over time by preventing misconfigurations from being deployed in the first place and help you avoid cloud drift.
At Bridgecrew, we’ve leaned into the built-in benefits of IaC to transfer the value of scalability and predictability to infrastructure security:
- Our open-source tool Checkov provides static analysis for IaC modules like Terraform, CloudFormation, and Kubernetes. We’re astounded by the community adoption—it’s been downloaded over 450K times in the past six months. If you’re not one of those 450K, you can install Checkov here.
- Our platform extends Checkov’s functionality to implement fixes as code and unify run-time cloud security posture monitoring with the IaC layer. You can try it out for yourself—it’s free to use up to 100 resources.
P.S. To get some exciting research we have coming up this month on the importance of IaC security, subscribe to our newsletter at bridgecrew.io/blog.
Top comments (0)