Cloud configuration security in Terraform

Why this area matters

Misconfigured cloud resources — storage open to the internet, databases with public endpoints, admin ports open to 0.0.0.0/0, encryption turned off — are behind a large share of cloud data exposures. Because they are declared in IaC, they can be caught in review before they are applied.

Trivy and Checkov know the rules for every resource type, but not your intent: a public bucket behind a static site is fine, a public bucket of exports isn't. The cloud agent reads the resource and its neighbors to tell the two apart.

What goes wrong in real applications

• Admin ports open to the internet

  SSH, RDP or database ports allowed from 0.0.0.0/0 expose them to constant automated login attempts and to any vulnerability in the service.

• Public data stores

  Buckets, databases and snapshots marked public can be read by anyone who finds them.

• Encryption disabled

  Storage, databases and backups without encryption at rest expose data if snapshots or disks are shared or leaked.

• Wildcard IAM

  Policies granting * actions or resources make every compromised credential an account-wide problem.

Sample: the risky pattern and the fix

resource "aws_security_group_rule" "ssh" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.app.id
}

resource "aws_db_instance" "main" {
  publicly_accessible = true
  storage_encrypted   = false
}

# No SSH ingress: operators connect through SSM Session Manager.

resource "aws_db_instance" "main" {
  publicly_accessible    = false
  storage_encrypted      = true
  kms_key_id             = aws_kms_key.db.arn
  db_subnet_group_name   = aws_db_subnet_group.private.name
  vpc_security_group_ids = [aws_security_group.db.id]
}

The original opens SSH to the whole internet and gives the database a public endpoint with unencrypted storage. The fix removes SSH ingress in favor of a managed session service, places the database in private subnets reachable only from the app's security group, and encrypts it with a managed key.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Terraform, CloudFormation, Pulumi YAML and Bicep/ARM templates (Trivy config / Checkov, then agent review)
• Security groups and firewall rules open to 0.0.0.0/0 or ::/0
• Public buckets, databases and snapshots; missing public-access blocks
• Encryption at rest and in transit, logging and versioning settings
• Whether exposure is intentional, such as a static website bucket or public CDN origin

Scope and limits

• It reviews IaC in the repository; it doesn't connect to your cloud accounts or scan deployed resources (it's not a CSPM).
• Resources created by hand or outside your IaC, and drift from what's declared, aren't visible.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Cloud security — Checks cloud resources for public exposure, wildcard IAM and long-lived keys.
• Infrastructure & IaC — Reviews Terraform, Helm, Ansible and server config for insecure defaults and exposure.
• Blast radius & data exposure — Assesses how much damage a compromise of this code could cause, and how to shrink it.