To make infrastructure provisioning consistent, scalable, and fast, infrastructure as code (IaC) has become a crucial component of modern cloud strategies. However, for all its flexibility and benefits, IaC comes with some drawbacks—especially concerning security and compliance.
Being aware of IaC security risks and challenges is the first step to fully embracing IaC to automate cloud security and shift it left. In this post, we’ll review some of those challenges and some ways to address them.
Because IaC is still relatively new, one of the biggest challenges teams face when adopting IaC is accurately integrating new frameworks with existing infrastructure. Whether you’re implementing a cloud-native declarative language like Terraform, or a cloud-agnostic imperative language like AWS CDK, translating complex and interconnected resources and their dependencies into code isn’t always straightforward.
Open-source tools such as Terraformer can offer some support, but adopting IaC will never be as simple as switching a flip. IaC adoption takes time, planning, and collaboration with other teams, including security and compliance. Gaps that exist along your IaC adoption journey can create confusion as to how and where your resources are provisioned, governed, and secured.
That’s why it’s essential to continuously audit your IaC adoption and communicate to avoid infrastructure drift and make sure your security tooling doesn’t get left behind.
As we’ve started to understand, bringing IaC into your stack may introduce added complexity. Much like bringing in a new open-source library or SaaS platform, IaC has the ability to improve efficiencies but needs the right level of buy-in and awareness. Keep in mind the learning curve your team will inevitably be subject to in coming to grips with a fundamentally different infrastructure approach.
With IaC, instead of managing infrastructure in one, centralized console, you have another framework running in parallel that should be your source of truth. If changes are made to infrastructure independent of the code provisioning it, you may experience significant drift that can result in substantial security issues without the proper monitoring in place.
That’s why it’s important to bear in mind that until you’ve fully embraced the immutable infrastructure movement, monitoring throughout the development lifecycle is a good idea. That way, you can catch issues in build-time before they’re deployed, and errors that may be introduced inadvertently after the fact in run-time.
Security tooling gets left behind
Research from ourselves and others has shown that IaC security has lagged. As many as one in two open-source infrastructure modules, such as those available contributed by GitHub or the Terraform Registry, contain missing or incorrect configuration that could lead to exposing resources to the public internet.
While that statistic doesn’t inherently represent risk, it does demonstrate a gap in how and where cloud security is being addressed in this value-chain. If developers use flawed IaC to build new resources, your provisioned infrastructure will contain those same misconfigurations. You might be thinking, “So what? That’s why I have Cloud Security Posture Management (CSPM) so that issues are quickly identified and resolved.”
While it’s true that CSPMs and other cloud monitoring tools provide real value, they’re reactive by design and can end up being at odds with your IaC efforts. With IaC in the picture, you may be creating more work for yourself by finding errors in run-time long after they’ve been merged and deployed. Not only can doing so create infrastructure drift—when code and infrastructure lose parity—but you’re also setting yourself up to face the same issues time and time again. The best way to address this discrepancy is to understand where policies are currently being enforced—in run-time or build-time—and try to shift as much of it as possible to the IaC layer.
New trends come and go, but we see IaC as the foundation for the next generation of security tools and workflows. Although it may cause some friction between security and engineering initially, it has the power to be a real agent of change for making cloud security more efficient and less obstructive. To achieve the benefits of IaC while eliminating friction, codify your cloud security with Bridgecrew.