Securing infrastructure as code: Perils and best practices

Some organizations are leaving themselves vulnerable when they adopt an infrastructure-as-code approach. Here's how to avoid misconfigurations and insecure templates.

Hands use a keyboard at a desktop display showing lines of code in a dimly lit workspace.
Husjur02 / Shutterstock

As organizations embrace cloud computing, the rate of infrastructure-as-code (IaC) adoption continues to rise. As with many new technologies, security is often bolted onto IaC or forgotten entirely. Securing IaC is important. Here’s how to best do so and the risks of neglecting this critical security activity.

What is infrastructure as code?

Traditional ways of deploying infrastructure involved procurement processes, physical infrastructure, long wait times, and server racks. Even with the advent of cloud computing, initial methods of managing infrastructure involved “click-ops”, as it is called, or manually going into the cloud service provider’s (CSP’s) console and instantiating infrastructure directly. This approach is inefficient, error prone, and doesn’t scale when dealing with enterprise cloud environments.

IaC changes this paradigm by allowing for the codification and programmatic management of infrastructure, much like you would do with traditional application code. This means you can use practices such as source control, versioning, re-use, portability, drift detection, and automation.

Popular IaC versions include CSP-specific flavors of IaC such as AWS’s Cloudformation or Azure’s Blueprints. There are also popular third-party IaC options with HashiCorp’s Terraform being the most popular with over 100 million downloads. The benefits of a third-party IaC is that it can be used across multiple CSP environments.

To continue reading this article register now

AWS, Google Cloud, and Azure: How their security features compare