infra-as-code-review

# Infrastructure-as-Code Review

Produce a structured infrastructure-as-code review that applies security, reliability, and operational quality standards to a specific body of IaC code. The output serves two purposes: an actionable review report for the code at hand (with findings by severity and specific remediation steps), and a reusable checklist the team can apply to every future IaC change. If the user provides actual code, analyze it and populate the findings table with real issues. If no code is provided, produce the checklist and a template findings report.

## Required Inputs

Ask for these if not already provided:
- **IaC tool** — Terraform, CloudFormation, Pulumi, Ansible, or CDK
- **Cloud provider** — AWS, GCP, Azure, or multi-cloud
- **What the code provisions** — a brief description (e.g., "VPC, EKS cluster, and RDS instance for the payments service")
- **Security policies or naming standards in use** — any existing org standards to check against; if none, use sensible defaults
- **The IaC code itself** — paste or describe it; if not provided, produce the checklist template only and note findings require code

## Output Format

---

# IaC Review Report: [What Is Being Provisioned]

**Reviewer:** [Name / Claude]
**IaC Tool:** [Terraform / CloudFormation / Pulumi / Ansible / CDK]
**Cloud Provider:** [AWS / GCP / Azure]
**Code Location:** [Repo path or PR link]
**Review Date:** [Date]
**Overall Risk:** [Critical / High / Medium / Low]

---

## Executive Summary

| Severity | Finding Count | Resolved in This Review | Carry-Over Risk |
|----------|---------------|------------------------|-----------------|
| Critical | [n] | [n] | [Yes/No — explain] |
| High | [n] | [n] | [Yes/No — explain] |
| Medium | [n] | [n] | [Yes/No — explain] |
| Low | [n] | [n] | [Yes/No — explain] |
| **Total** | **[n]** | **[n]** | |

**Recommendation:** [Approve / Approve with Required Changes / Block — one sentence rationale]

---

## Findings

### Critical Findings

#### CRIT-01: [Finding Title]

| Field | Detail |
|-------|--------|
| **Severity** | Critical |
| **Category** | [IAM / Secrets / Encryption / Network / State / Naming / Cost] |
| **Resource** | `[resource_type.resource_name]` |
| **File / Line** | `[path/to/file.tf:42]` |
| **Risk** | [What can go wrong — be specific about the attack vector or failure mode] |

**Current code:**
```hcl
# [paste the problematic snippet]
resource "aws_s3_bucket" "data" {
  bucket = "my-bucket"
  acl    = "public-read"   # PROBLEM: public read access
}
```

**Remediation:**
```hcl
resource "aws_s3_bucket" "data" {
  bucket = "my-bucket"
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}
```

**Why this matters:** [One sentence linking the specific risk to business impact — data exposure, compliance violation, etc.]

---

#### CRIT-02: [Next Critical Finding — repeat structure]

---

### High Findings

#### HIGH-01: [Finding Title]

| Field | Detail |
|-------|--------|
| **Severity** | High |
| **Category** | [Category] |
| **Resource** | `[resource_type.resource_name]` |
| **File / Line** | `[path/to/file.tf:line]` |
| **Risk** | [Specific risk description] |

**Current code:**
```hcl
# [problematic snippet]
```

**Remediation:**
```hcl
# [fixed snippet]
```

---

### Medium Findings

#### MED-01: [Finding Title]

| Field | Detail |
|-------|--------|
| **Severity** | Medium |
| **Category** | [Category] |
| **Resource** | `[resource_type.resource_name]` |
| **File / Line** | `[path/to/file.tf:line]` |
| **Risk** | [Specific risk description] |

**Remediation:** [Prose or code snippet — choose whichever is clearer for this finding]

---

### Low Findings

#### LOW-01: [Finding Title]

| Field | Detail |
|-------|--------|
| **Severity** | Low |
| **Category** | [Category] |
| **Resource** | `[resource_type.resource_name]` |
| **File / Line** | `[path/to/file.tf:line]` |
| **Suggestion** | [What to improve and why] |

---

## Reusable IaC Review Checklist

Use this checklist on every IaC pull request. Check every item; mark N/A only when the item genuinely does not apply to the resources being provisioned.

### 1. IAM and Access Control

- [ ] No wildcard actions (`"*"`) in IAM policies — policies follow least-privilege
- [ ] No wildcard resource (`"*"`) in IAM policies unless explicitly justified with a comment
- [ ] IAM roles use condition keys to restrict scope (e.g., `aws:RequestedRegion`, `sts:ExternalId`)
- [ ] No IAM access keys or credentials hardcoded or in plaintext variables
- [ ] EC2 / compute instances use instance profiles, not hardcoded credentials
- [ ] S3 bucket policies do not allow public access unless the bucket is explicitly a public asset bucket
- [ ] Cross-account trust policies name specific account IDs, not `"*"`
- [ ] Service accounts (GCP) / managed identities (Azure) follow naming conventions and have documented purpose

### 2. Secrets Management

- [ ] No secrets, passwords, tokens, or API keys in plaintext in any `.tf`, `.yaml`, or `.json` file
- [ ] No secrets in variable default values
- [ ] Secrets sourced from Secrets Manager / Parameter Store / Vault — not from environment variables passed at plan time
- [ ] `sensitive = true` is set on all output values and variables that contain secrets (Terraform)
- [ ] State backend is encrypted — no unencrypted state files contain sensitive data
- [ ] `.gitignore` or equivalent excludes `*.tfvars`, `terraform.tfstate`, and any file that may contain resolved secrets

### 3. Encryption at Rest

- [ ] Storage resources (S3, EBS, RDS, DynamoDB, GCS, Azure Blob) have encryption at rest enabled
- [ ] Customer-managed keys (CMK/KMS) are used where required by policy — not solely AWS/GCP/Azure managed keys
- [ ] KMS key rotation is enabled for all CMKs
- [ ] Database snapshots have encryption enabled
-