Infrastructure-As-Code in the Cloud & Why it Matters in DevSecOps

What is Infrastructure-as-Code (IaC)?

Infrastructure-as-Code (IaC) is the practice of defining templates that can be used to provision technology infrastructure to support software and applications. Traditionally, physical hardware configuration of network switches/routers, servers, network-attached storage, etc. has been a time-consuming and difficult task that not only was prone to human error—but was also not easily repeatable. Even after the advent of virtualization and the automated software configuration revolution, technology infrastructure was still built on a backbone of (usually) manually-managed hypervisors overseen by IT operations staff.

A small snippet of an AWS CloudFormation template using YAML syntax.

With the rise in popularity of public cloud platforms like AWS and Azure, the idea of managing and configuring infrastructure automatically via predefined code and templates has emerged. This was difficult to manage previously simply because traditional on-premises datacenters did not have programmatic interfaces (APIs) that enabled actions to be defined and executed automatically. The usage of individual and non-integrated scripting in operational work tasks did not provide the same capabilities and error controls as APIs now provide. This paradigm shift in computing has enabled tasks requiring physical configuration—like racking a server in a datacenter to host an application—to be abstracted as a handful of code that can be replicated infinitely.

A Terraform execution plan.

Why does IaC matter & how does it impact DevSecOps?

This brings us to the central point—why does this matter—and more specifically how does this impact DevSecOps? The points below are not listed in any particular order.

• Removes deployment effort. This assertion is rather straightforward, but is still worth mentioning. Using a tool like CloudFormation or Terraform takes the manual effort of provisioning infrastructure resources and configuring them to support your workloads and distills this to the simple press of a button. This simplicity and reduction of effort dovetails quite nicely with a main pillar of DevSecOps: reduction in time to market, or to put it in a less eloquent manner—“go fast.” It has the added benefit of allowing resources contained in IaC templates to be managed as “bundles” rather than individual components.
• Makes deployments repeatable and scalable. IaC allows the same deployment to be replicated infinitely by executing the code multiple times. The amount of effort saved is magnified depending on how many times the infrastructure needs to be replicated. DevSecOps pipelines are constructed to be repeatable, and this allows the technology infrastructure components of DevSecOps to be idempotent across deployments. Furthermore, the same template can be applied on a truly impressive scale simultaneously. For example, using the CloudFormation StackSets feature, a deployment can be replicated across multiple AWS Accounts with a single execution.
• Merges technology infrastructure with workloads and applications, unifying operations and development. One of the oldest partitions in the IT industry has been the division between “operations” and “development.” This partition makes complete sense in a world where manual configuration is required to enable the networking, storage, and compute resources needed to run applications and workloads. However, IaC allows us to rethink this outmoded partition—what if we perceive our application or workload as a combination of technology infrastructure components AND the code that runs on them? This idea is of course foundational to the word “DevOps” itself, being a contraction of the originally partitioned functions of “development” and “operations”. IaC is a manifestation of this DevOps philosophy. It allows “operations” to be defined as code and implemented automatically.
• Reduction in human error leads to improvements in security and quality. While this might seem self-evident, we believe that this is also fundamental to DevSecOps. A major impetus in the adoption of DevSecOps for many teams and companies is to enshrine what used to be a process in code—to ensure that the process is executed correctly despite the myriad complexities that arise during the delivery of software. This is why DevSecOps is required to elevate “delivery” to “continuous delivery.” Furthermore, IaC as a component of DevSecOps improves the quality and security of applications and workloads. In most major public cloud platforms, IaC can be responsible for incorporating network security and the configuration of assets like firewalls, security groups, NATs, access controls lists, etc. It can further be used to ensure that this is done correctly and prevent ubiquitous security oversights by executing the configuration flawlessly.
• Storing infrastructure as code allows it to be maintained in version control—keeping a record of all changes and the current state of the infrastructure. Regardless of whether your preferred version control system is Git or Subversion, utilizing IaC allows updates and changes to infrastructure components to be captured and tracked over time. This is a fantastic way to increase visibility and auditability. In this manner, the code itself serves as a form of documentation. When changes are made, templates reflect the changes—which can serve as a remedy to the classical problem of configuration drift. From the perspective of DevSecOps, this is greatly impactful as maintaining this configuration in a common version control system allows for collaboration among and across agile cross-functional teams. In addition, the use of version control is typically associated with higher-performing teams.

A small snippet of a Terraform template.

How does IaC influence cloud strategy & continuous delivery?

IaC is now pervasive across public cloud providers. Mature DevSecOps practitioners are adopting or have already adopted IaC as a component of their continuous integration/ continuous delivery (CI/CD) pipelines. IaC is an important component of enabling true continuous delivery when technology infrastructure is involved.

It should be noted that IaC becomes much simpler to implement in cases where technology infrastructure is already abstracted, or in services that tend to function in a PaaS (Platform as a Service) model rather than IaaS (Infrastructure as a Service) model. For example, using a service like AWS’s Elastic Beanstalk can automatically provision and deploy technology infrastructure components designed to run applications and workloads and then customize them based on parameters that you provide. Similar functionality is present in other platforms like Google Kubernetes Engine (GKE), Heroku, or Azure Container Instances. In much the opposite way, adoption of IaC can be challenging in hybrid cloud environments where different platform-restricted template/coding languages may influence the choice of IaC flavor—HashiCorp’s Terraform is known for attempting to be the one-size-fit-all solution in these cases. Regardless—IaC should be considered a crucial part of any cloud strategy and CI/CD pipeline. It provides a method of capturing cloud architecture as code—and by enabling the rapid deployment and revision of this infrastructure it can influence the creation of a cloud operating model as well.

Watch for more from Impact Makers’ Cloud Experts

In this blog, tools like Terraform, CloudFormation, and Azure Resource Manager templates were discussed—but the details and advantages of these different technologies was never expounded upon. Look forward to posts on this in the future!