How to adopt infrastructure as code with a secure-by-default strategy

Since its inception, infrastructure as code (IaC) has transformed how application infrastructure is provisioned and configured. IaC allows you to easily manage, configure, update, secure, and scale your infrastructure via imperative or declarative configuration files. When built into your cloud strategy, IaC addresses notorious cloud challenges like scalability, availability, and consistency.

Unfortunately, overlooking security considerations when first adopting IaC is all too common. Whether porting brownfield apps or building greenfield apps with IaC, it’s important to apply traditional security best practices to IaC. A reactive approach to security introduces complexity and friction that could be avoided by integrating security into your IaC strategy from day one.

In this post, we’ll review what happens when you don’t proactively address IaC security and provide guidance to get you started as you build your security-first IaC strategy.

Common problems with overlooking security as you build your IaC strategy

Infrastructure as code provides a wide range of benefits and opportunities for development and DevOps teams, but ignoring security while building an IaC strategy can lead to misaligned security feedback and gaps down the line. When teams have to shore up their cloud infrastructure security after they’ve already embedded IaC in their workflows, there are a few common challenges they face:

The misconfiguration snowball effect

The IaC misconfiguration snowball effect can be a major pain point for teams that adopt IaC without building in security. IaC allows you to quickly deploy multiple environments at scale, but that also means that a single misconfiguration in your IaC codebase pre-deployment can result in your team fielding thousands of identical alerts across your replicated environments down the line.

To mitigate the snowball effect, you have to identify and address issues at the source. Whether you surface feedback during development or build-time, stopping misconfigurations early will dramatically reduce the amount of time your team spends triaging and addressing misconfigurations.

Cloud infrastructure drift

When teams adopt IaC but ignore the GitOps best practice of honoring their configuration files as the single source of truth, they run the risk of introducing cloud infrastructure drift. Cloud drift occurs when the configuration of infrastructure in your runtime environment does not perfectly match the configuration of infrastructure in your build-time environment. Drift most often happens when someone on the Ops team makes a change to a running cloud resource out of band from the IaC file that was originally used to provision it.

Drift reduces your team’s visibility into your resources and negates many of the benefits of IaC. It can also make it more challenging to identify misconfigurations. While the best approach is to maintain GitOps best practices and make all changes within IaC, it’s still important to have code to cloud visibility for when drift does inevitably happen.

Overlooking open-source IaC components

Many teams don’t account for the fact that much of their IaC uses open-source code components. While open-source code simplifies and expedites the IaC adoption process, these code components most likely have misconfigurations. For example, our research indicates that about half of open-source Terraform templates contain misconfigurations.

Without a security-first approach to IaC, those misconfigurations are easy to miss and get deployed to production, becoming alerts for your security team to triage or, worse, weaknesses that bad actors can exploit. By embedding IaC security scanning into your tools and workflows, you can ensure that misconfigurations are identified and remediated before they are ever deployed into runtime environments.

How to build a security-first IaC strategy

Now that we’ve covered some common challenges when infrastructure as code security is overlooked, let’s talk about how you actually go about adopting a secure-by-default IaC strategy. These practices will help you build a top-notch IaC strategy that keeps cloud infrastructure security top of mind:

Rely solely on your configuration files for information about your infrastructure

It’s a best practice to maintain all specifications of your infrastructure in configuration files only with no additional documentation needed. This way, your configuration files constitute your entire infrastructure and can be referenced quickly to identify any security concerns.

Employ version control

Keep all your configuration files under source control using a tool like GitHub or GitLab. Version control gives you greater visibility into your cloud environment by providing information about changes to your configuration files, like which developer introduced a misconfiguration when they merged a specific pull request. Version control also allows you to quickly roll back to previous versions of files if any security concerns are identified.

Maintain GitOps to establish parity and clarity

Making your Git repository the single source of truth for all your cloud resources in your runtime environment is crucial when leveraging IaC. While drift is not a security concern in and of itself, it can present security gaps and challenges identifying misconfigurations.

For example, if your team is fixing cloud misconfigurations in runtime rather than at the source, the secure configuration will be overwritten whenever someone on your team reapplies the IaC.

Take advantage of all the IaC automation tools available

IaC is code, and therefore it should be tested just like any other code. IaC is what enables shift-left security or DevSecOps for infrastructure, so capitalize on that opportunity!

With IaC linters and security scanners, you’ll be able to validate that IaC is functional and secure before it’s deployed. Many tools, such as our own open-source security scanner, Checkov, exist as CLIs or IDE plugins, allowing for feedback as you’re writing and editing IaC. SaaS platforms such as Bridgecrew also provide native integrations with your VCS provider to make IaC feedback collaborative and in sync with your version control.

Whether you’re using open-source tools or SaaS platforms, it’s a best practice to add multiple checkpoints across the development lifecycle—from code and commit to build and deploy. This is especially important for IaC because while addressing issues as early as possible is cheaper and faster, you gain more representation of resources the closer they are to their runtime state.

Leveraging automation within IaC will reduce the number of runtime errors and alerts, thus minimizing time spent on repetitive security tasks.

Implement a tagging strategy for code to cloud security traceability

Consistently tagging resources is essential if you want to properly document and manage your cloud resources. However, manual tagging quickly becomes impossible as your cloud scales up. This is where automated tagging and tracing of your IaC comes in.

Using an automated IaC tag rule manager like Yor enables you to centralize your tagging management and consistently apply tags across your repositories and organizations. With a consistent tagging strategy, you can quickly identify the files and lines of code that caused a runtime misconfiguration, locate where else those misconfigurations exist in your runtime environment and identify the developer on your team who last edited the code and can remediate the issue.

Set up your CI/CD pipeline with security in mind

CI/CD pipelines are vital for compiling, validating, and provisioning IaC. They provide an opportunity to embed security guardrails before IaC is deployed, but when not hardened, they also give bad actors a vector to gain privileged access.

Keeping your CI/CD pipeline secure requires consistent auditing and maintenance of all owned and third-party CI/CD elements. Additionally, enforcing least privileged roles and permissions is crucial to minimize unauthorized access and avoid malicious code injection into your pipeline. You can also leverage IaC to create a known safe environment for each development and test lifecycle iteration.

Determine how to store your secrets securely

Having credentials readily at hand for the right people at the right time is vital to agile development, but storing them in the wrong place can give bad actors the keys to your critical infrastructure and sensitive data. Make sure you’re using a vault system for secrets encryption. Vaults will embed secrets into environment variables in your runtime environment and will require authentication methods to access those secrets. When you enable multi-factor authentication and other secure authorization measures, you’ll ensure that there are multiple layers of security protecting your secrets.

Even if you only use vaults to encrypt your secrets, sometimes mistakes happen, and a developer embeds credentials in code. Because bad actors can easily steal these secrets by inspecting your code, you’ll want to scan your IaC templates for secrets in addition to using a secrets vault.

Adopting IaC can be an exciting time as you take advantage of all the different automation and optimization capabilities IaC offers. IaC also presents an opportunity to scale your cloud environments without compromising security but requires a strategic plan that is secure by default from the start. As you get ready to expand your IaC security adoption, check out this process for building an IaC security and governance program for inspiration.