Hardening Production Infrastructure with Terraform Security Groups

As cloud infrastructure expands to serve a multitude of production workloads, crafting robust network security postures is critical.

Poorly configured access controls leave businesses exposed to crippling attacks and data breaches. Nearly 70% of companies report experiencing a cloud security incident over the past year.

Terraform provides powerful tools for defining and enforcing security groups to selectively filter traffic between cloud resources. Combined with sound architecture, it enables engineers to embed preventive security measures programmatically into infrastructure.

This guide explores patterns and benefits of managing AWS security groups with Terraform for production use cases. Read on to harden your cloud deployments.

The Critical Role of Security Groups in Production

Security groups act as a first line of defense in cloud networks to allow/deny traffic flowing between resources.

Rules explicitly permit desired connections while implicitly denying everything else by default. This model prevents overlooked openings compared to more complex ACLs or firewalls that require exhaustively stating all denied traffic.

For productions workloads especially, sound security groups are crucial given the risks posed by any unauthorized access. Common weak points targeted by attackers include:

• Exposed databases allowing uncontrolled queries
• Undocumented maintenance ports lingering opened to public
• Unrestricted connectivity between application tiers enabling lateral movement

Implementing least privilege rules govern allowed engagement pathways. Segmenting permissions based on environment and resource function provides control granularity.

Up 46% of companies however report lacking sufficient cloud security skills to define and manage appropriate controls. This gap highlights the value of leveraging Terraform to compensate for gaps in cloud network defensive expertise.

Streamlining Security Group Management with Terraform

While native cloud console dashboards enable configuring security groups via point-and-click, such manual efforts do not scale efficiently.

Teams managing dozens of groups with evolving edits over years grows highly complex. Minor oversights create drastic vulnerabilities while validations stay imprecise.

Terraform proves transformational for security group management by enabling:

• Infrastructure-as-code – Security rules and settings defined in version controlled config files that act as source of truth
• Validation – Misconfigurations detected before provisioning prevents cloud incidents
• Auto-generation – Entire multi-tier schemes generated from modular code portions
• Change automation – Alter security postures rapidly across multiple environments
• Access controls – Permission security group usage via Terraform changesets

Top cloud leaders like Netflix, Spotify, and Heroku utilize these capabilities at massive scales to stay secure.

Terraform security group management at scale. (Source: Yevgeniy Brikman, Gruntwork)

Now that we‘ve motivated the need for robust security groups let‘s explore production-grade implementation strategies with Terraform.

Deploying Defense-in-Depth Security Group Architecture

Crafting layered security requires structured direction. Simply opening ports because traffic gets blocked leads to disorder.

We‘ll design a purpose-driven scheme following security best practices of defense-in-depth:

• Apply controls as close to resource as possible
• Assume breaches will occur eventually
• Establish concentric rings of increasing trust
• Least privilege permissions strict as possible

This philosophy pressures tests protections across increasing depths. Each layer remains secured irrespective of outer deficiencies.

Defense-in-depth security layers principle

We‘ll demonstrate building this architecture style for a customer-facing production web application highlighting key Terraform modules.

Public Zone Security Groups

Resources accepting direct external traffic require hardened public zone security groups even if fronted by a WAF or CDN.

Our inbound customer traffic first hits public facing Application Load Balancers (ALBs) that proxy requests to backend application servers.

We‘ll permit only essential HTTP/HTTPS ingress connectivity necessary:

# public_alb_sg.tf
resource "aws_security_group" "public_alb" {
  name = "public-alb-sg"
  ingress {
    description = "Allow HTTP"
    from_port = 80 
    to_port = 80
    protocol = "tcp"
  }

  ingress {
    description = "Allow HTTPS"  
    from_port = 443
    to_port = 443
    protocol = "tcp"
  }
}

This simple module allows no more exposure than necessary for customers to access the application.

Resources receive only explicitly allowed ingress while blocking all other implicit traffic. Security groups attached restrict returned traffic downstream also.

Next, we stage a set of public EC2 Bastions allowing temporary administrative SSH access past the ALBs if necessary:

# public_bastion_sg.tf  

resource "aws_security_group" "public_bastion" {
  name = "public-bastion-sg"

  ingress {
    description = "Allow SSH Admin Access"         
    from_port = 22
    to_port = 22  
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port = 0 
    to_port = 0
    protocol = "-1"
  }  
}

Note access opens only from approved operations subnets despite more exposure than preferred long term.

This completes our public zone module following least privilege principles. Resources remain inaccessible and isolated beyond these controlled connections from customers and staff.

Application Tier Security Groups

The next defense layer secures our application delivery tier itself only permitting:

• HTTP/HTTPS ingress from public ALBs
• Outbound connectivity to supporting backend services

This middle layer handles scalable request processing that transforms and prepares data for the presentation layer.

Our module ensures apps receive no unexpected inbound flows from frontends:

# app_tier_sg.tf

resource "aws_security_group" "app_tier" {   
  name = "app-tier-sg"

  ingress {
    description = "Allow ALB Traffic"
    from_port = 80
    to_port = 80  
    protocol = "tcp"
    security_groups = [aws_security_group.public_alb.id]
  }

  ingress {
    description = "Allow ALB TLS Traffic"
    from_port = 443 
    to_port = 443  
    protocol = "tcp"
    security_groups = [aws_security_group.public_alb.id]
  } 
}

Note all inbound dependencies route via ALB rather than direct external access. This isolates risk if the ALB faces compromise via fewer pathways for lateral movement.

Outbound we‘ll enable unrestricted connectivity through to backend data dependencies:

egress {
  description = "Allow Unrestricted Backend Egress"  
  from_port = 0
  to_port = 0 
  protocol = "-1" # All protocols
}

Terraform permits simple one-liner declarations to open bidirectional flows between resources.

This model right-sizes permissions for apps while precluding unanticipated ingress vectors internally.

Database Tier Security Groups

Finally, we focus on securing sensitive backend database clusters storing customer data assets and powering site functionality.

These persistence layers enable managing and operating application data flows, but pose immense risk if compromised. Attackers utilizing stolen credentials or exploiting SQL injection paths aim to achieve backend database access.

We eliminate upstream ingress vectors and any notion of open management consoles:

# database_sg.tf

resource "aws_security_group" "databases" {
  name = "database-sg"

  ingress {
    description = "Allow App Tier Cluster Traffic"
    from_port = 3306 
    to_port = 3306
    protocol = "tcp"
    security_groups = [aws_security_group.app_tier.id] 
  }  
}   

This simple module only permits MySQL flows originating from application servers secured earlier. No SSH or RDP exposure risks getting provisioned lingering open to the internet.

Meanwhile, requisite outbound connectivity remains open for replicating, backing up, analyzing, and managing data:

egress {
  from_port = 0
  to_port = 0
  protocol = "-1" 
}

This completes our defense-in-depth scheme restricting traffic to least privilege rules between each tier:

Additional controls get layered atop like IDS systems, VPC flow logs, and WAF appliances to further pressure test for weaknesses.

Balancing Security Group Complexity vs Risk

When structuring security groups, excessive complexity introduces risk comparable to overly permissive defaults.

Engineers face constant tension balancing:

• Simplicity – Easy to verify correctness and intended behaviors
• Granularity – Managing traffic at most discrete levels possible

Signs of overly complex schemes include:

• Deep chains of explicitly interlinked group dependencies
• Hundreds of disjointed, disorganized individual groups
• Unwieldy rule expanses numbering thousands

Symptoms of such entanglement include inability to accurately reason about implications of changes downstream and unforeseen connection losses violating assumed functionality.

Excessively permissive designs conversely hazard outright exposed resources and movement opportunities violating restrictions.

Mitigations to balance trade-offs:

• Segment module by network zones over micro-carving each tier
• Deliberately highlight, sever intricate dependency chains
• Favor rule precision with larger net blocks like VPC CIDRs over individual point IPs
• Streamline groups down to essential attributes rather than endless expansion

Target simplicity where possible, turning to precision when risks necessitate.

Additional Best Practices for Production Security Groups

Beyond core traffic management controls, several supplementary measures tighten security group productions risks further:

Launch configurations overwrite removal – Ensure decommissioned groups get destroyed fully rather than left disabled:

resource "aws_security_group" "closed_sg" {

  ...

  lifecycle {
    create_before_destroy = true
  }
}

Ingress rule descriptions – Explicitly detail reason and context for exposed paths:

ingress {
  description = "Allow inbound migrations from operations subnet"
  from_port = 22
  to_port = 22
}   

Resource tagging – Identify security group to attached resources easing analysis:

tags = {
  associated_ec2 = "public_web_1" 
}

Revocation on deletes – sever residual dependencies by revoking rules automatically:

revoke_rules_on_delete = true

Closing Recommendations

Implementing cloud network security requires addressing the fundamentals across sides of prevention, detection, and recovery.

Terraform offers a powerful tool for engineers to drive consistency, efficiency, safety, and scale into cloud security group controls as key preventative protections.

Blending sound architectures, least privileges access, centralized policies, and embedded DevSecOps deliver robust end-to-end security group postures safeguarding production systems.

As businesses continue migrating sensitive application stacks into public cloud infrastructure consuming Terraform, prioritizing properly configured groups will strengthen environments against data breaches that erode customer trust if neglected.

What security enhancements stand to best harden your stack? Reach out for guidance tailoring protections for modern cloud application needs.