Skip to content

Infrastructure as Code (IaC)
and Security

As organizations continue to scale their usage of public cloud and release software more regularly, manually creating infrastructure in cloud management consoles is no longer sustainable. Today, DevOps and cloud engineering teams are leveraging cloud provider APIs and IaC tools like Terraform to programmatically define infrastructure “resources” (such as an Amazon S3 bucket or Google compute engine VM) as code.

What is Infrastructure as Code?

In short, infrastructure as code (IaC) is all about defining cloud infrastructure in a programming language. This enables you to apply software development principles such as version control and continuous integration/continuous delivery (CI/CD) to the testing and deployment process. You declare the configuration you want the infrastructure in your cloud environment to have and then use IaC tools to deploy that configuration and create the corresponding infrastructure.

With the introduction of infrastructure as code (IaC), a server can now be defined like this:

lac-image1

This is an Amazon Web Services EC2 instance defined in Terraform's HCL language! We'll explain this in a bit.

What does IaC look like?

There are a number of tools and languages for defining infrastructure-as-code. Terraform is the most popular cross-platform IaC framework, though each cloud provider has their own alternative (e.g., AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager).

As an example, you can "declare" an AWS S3 bucket using Terraform's HCL language like so:

image

Terraform takes this code and leverages AWS APIs to "provision" the Amazon S3 bucket in your AWS account. The example at the beginning of this document was also written in HCL.

Here's the same bucket defined in AWS CloudFormation:

image

IaC benefits

By treating infrastructure like code, you introduce a number of benefits:

  1. Speed:
    You can quickly launch pre-approved infrastructure instead of painstakingly creating it by hand every time. A single code template and command can create (and destroy!) thousands of cloud resources in minutes. This enables development teams to push out new features quickly.
  2. Security and Quality:
    IaC templates can be evaluated by tests and reviewed by security teams. This means the end result is higher quality infrastructure with fewer functional and security issues.
  3. Consistency:You can consistently deploy infrastructure and know that you'll end up with exactly what the IaC defines -- every single time.
  4. Version Control:
    You can keep IaC in version control, most commonly done with a tool like GitHub or GitLab, so you can track code changes, collaborate on code reviews, and roll back infrastructure to a previous state if needed.
  5. Test and Deploy Automation:
    You can use CI/CD systems, such as Jenkins or CircleCI, to automatically run tests on your infrastructure at different stages of development, and also deploy to the cloud runtime environment. This enables fully automated security and compliance validation, so potential misconfigurations are caught before any cloud infrastructure is created.

IaC is part of the CDLC

IaC is part of the cloud development lifecycle (CLDC), which is the subset of the software development lifecycle (SDLC -- you’ve probably heard this term!) that focuses on cloud infrastructure.

The CDLC is composed of these phases:

  • Development
  • Deployment
  • Runtime

IaC touches all three phases. You write IaC during the development phase and provision the infrastructure by executing the code during the deployment phase. Once the infrastructure is running, you can go back and update the IaC to propagate changes at runtime.

There are multiple opportunities for automated security and compliance checks in the CDLC. This means there are multiple ways that Fugue can help in this process.

For more information about the CDLC, see [The Cloud Development Lifecycle (CDLC)].

IaC gotchas & things to be aware of

Infrastructure as code delivers enormous benefits, but organizations still need to pay close attention to other areas:

  • Don’t focus only on IaC/what happens pre-deployment -- runtime operations matter. There are lots of nuances to cloud infrastructure that can only be assessed and managed at “runtime”:
    • Cloud providers have a lot of default resources, configurations, and behaviors that aren't always managed with IaC. For instance, Amazon S3 “MFA delete” can only be configured with the cloud console/CLI.
    • Cloud resources are often interconnected. For example, an IAM policy defined at the account level governs access to a subset of storage resources -- and these relationships often won’t be captured within IaC templates that typically focus on individual resources.
  • Configuration drift happens. Inevitably, organizations still need to make changes to cloud infrastructure within the cloud management console or with individual CLI commands. This often happens during testing, or may be a case of human error. The result is that runtime infrastructure “drifts” from IaC definitions, and these need to be reviewed and reconciled.
  • Cloud security starts with code: As organizations shift to using IaC, code security becomes all the more important. Resources that are misconfigured in code will become misconfigured runtime resources -- and with the speed and scale that IaC enables, this can quickly become an enormous security headache.

Why IaC Security is Important

With infrastructure as code, security is especially critical. Here are some tips.

  • Identifying potential security and compliance gaps earlier reduces risk. Proactively identifying and remediating misconfigurations in code enables security engineer teams to remediate issues before any infrastructure is created. IaC security tests can be integrated early in the development process, such as when writing code, “commiting” code to a repository, or prior to a deploy.
  • Small IaC misconfigurations can become large runtime attack surfaces. Because IaC templates enable rapid, potentially high-volume deployment of resources -- and because IaC templates are often reused by teams - even single-line misconfigurations can have enormous impact on many cloud resources.
  • Be aware that some runtime configurations can’t be “fixed.” Many resources, such as Amazon RDS instances or EBS volumes, have configuration settings -- such as encryption -- that cannot be changed once an instance or volume is “live."
  • Securing IaC templates frees up security teams to focus on runtime issues. By fixing potential misconfigurations in IaC (when things are easier to resolve!), security engineers have more capacity to focus on how IAM permissions, interconnected and ephemeral resources, and out-of-band modifications affect security posture.
  • Development security fosters a culture of security. Every person has an effect on your organization's security and your security posture is only as strong as your weakest link.

How Fugue Can Help

Fugue discovers resources in infrastructure as code (IaC) templates and in the cloud and checks these resources for security issues, compliance violations, and other misconfigurations. When teams use Fugue in their development workflows and CI/CD pipelines, they receive feedback about these security deficiencies and misconfigurations early in the development process. This automation and rapid, early feedback means engineers can iterate more quickly and be much more confident in the security of the infrastructure they build and operate.

Cloud engineering teams use a variety of tools and services to get their job done. Fugue easily integrates with the tools and workflows your team already has in place. This includes supporting a variety of code repositories, CI/CD services, and IaC template formats.

Learn more about how Fugue can help you secure your infrastructure as code.