DevSecOps Like a Pro — A Chill Intro to Terraform

As the world of technology continues to evolve, managing infrastructure can become quite challenging, especially in large technology organizations. In my experience working at a big tech company, I’ve seen firsthand the difficulties that come with traditional infrastructure maintenance. A common problem is the potential security vulnerabilities that arise during staff transitions, when a complete understanding of the production environment is often lacking.

A “cool” handover process

That’s where Terraform come in.

Terraform is an open source Infrastructure as Code (IaC) tool that allows users to define and manage their infrastructure using a declarative language called HCL (HashiCorp Configuration Language). It offers several benefits such as scalability, version control, and collaboration, making it an awesome solution for managing large infrastructures more efficiently. Here’s a simple HCL example using Terraform for AWS, where we create an Amazon S3 bucket with server-side encryption enabled for increased security:

resource "aws_s3_bucket" "supasaf_bucket" {
  bucket = "my-secure-bucket-239827"
  acl    = "private"

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "aws:kms"
        kms_master_key_id = aws_kms_key.supasaf_key.arn
      }
    }
  }
}

resource "aws_kms_key" "supasaf_key" {
  description             = "KMS key for S3 bucket"
  deletion_window_in_days = 7
}

We can check the deploy in AWS console as follows:

Unlike traditional infrastructure management, which typically involves manual processes, lack of standardization, and limited visibility, Terraform code can be stored in version control systems, allowing for better tracking and management of infrastructure changes. Its modular design encourages collaboration and code reuse, resulting in a more streamlined and consistent infrastructure build.

One of the key benefits of using Terraform is improved visibility and security. By using Terraform’s declarative language and version-controlled code base, we gain greater insight into the infrastructure setup, reducing the likelihood of security vulnerabilities resulting from a lack of understanding. In addition, Terraform’s modular design and reusable code components make it easier to enforce security best practices across the infrastructure, minimizing potential risks during staff transitions.

Another challenge of managing cloud infrastructure is ensuring that the resources are configured according to security best practices and compliance standards. For example, you might want to enforce that all your cloud storage buckets are encrypted, or that all your network firewalls have the right rules. Terraform can help you achieve this by using policy as code, which is a way of defining and enforcing security policies using code. Policy as code allows you to automate security checks and validations, and prevent or correct any deviations from the desired state.

One of the tools that supports policy as code for Terraform is Sentinel, a framework that allows you to write flexible and expressive policies using a high-level language. Sentinel policies can be applied to Terraform plans, states, and configurations, and can be integrated with Terraform Cloud or Enterprise. Here’s an example of a Sentinel policy that checks if all AWS S3 buckets have encryption enabled:

import "tfplan/v2" as tfplan

violatingS3Buckets = filter tfplan.resource_changes as _, rc {
 rc.type is "aws_s3_bucket" and
  rc.mode is "managed" and
  (rc.change.actions contains "create" or rc.change.actions contains "update") and
  (rc.change.after not contains "server_side_encryption_configuration" or
   length(rc.change.after.server_side_encryption_configuration) == 0)
}

for violatingS3Buckets as address, bucket {
 print(address + " does not have server side encryption configured.")
}

main = rule {
 length(violatingS3Buckets) == 0
}

Another option is using OPA, an open source, general-purpose policy engine that can be used to enforce policies across different domains, such as Kubernetes, Docker, Terraform, and more. OPA policies are written in Rego, a declarative logic language that allows you to express complex rules and queries. OPA policies can be evaluated against any JSON data, such as Terraform plans, states, and configurations. Here’s an example of using OPA to check if all AWS S3 buckets have encryption enabled:

package terraform

import input.tfplan as tfplan

allowed_acls = ["private"]
allowed_sse_algorithms = ["aws:kms", "AES256"]

s3_buckets[r] {
    r := tfplan.resource_changes[_]
    r.type == "aws_s3_bucket"
}

array_contains(arr, elem) {
  arr[_] = elem
}

# Rule to restrict S3 bucket ACLs
deny[reason] {
    r := s3_buckets[_]
    not array_contains(allowed_acls, r.change.after.acl)
    reason := sprintf(
        "%s: ACL %q is not allowed",
        [r.address, r.change.after.acl]
    )
}

# Rule to require server-side encryption
deny[reason] {
    r := s3_buckets[_]
    count(r.change.after.server_side_encryption_configuration) == 0
    reason := sprintf(
        "%s: requires server-side encryption with expected sse_algorithm to be one of %v",
        [r.address, allowed_sse_algorithms]
    )
}

# Rule to enforce specific SSE algorithms
deny[reason] {
    r := s3_buckets[_]
    sse_configuration := r.change.after.server_side_encryption_configuration[_]
    apply_sse_by_default := sse_configuration.rule[_].apply_server_side_encryption_by_default[_]
    not array_contains(allowed_sse_algorithms, apply_sse_by_default.sse_algorithm)
    reason := sprintf(
        "%s: expected sse_algorithm to be one of %v",
        [r.address, allowed_sse_algorithms]
    )
}

Terraform was release in 2014, it has been widely adopted by the industry. I hope you enjoyed this chill intro to Terraform and how it can help you with your DevSecOps goals. Happy coding!