Project 11: “The AWS Cloud Architect” — Cloud Infrastructure

Attribute	Value
File	KIRO_CLI_LEARNING_PROJECTS.md
Main Programming Language	Terraform / AWS CLI
Coolness Level	Level 3: Genuinely Clever
Difficulty	Level 3: Advanced
Knowledge Area	Cloud Infrastructure

What you’ll build: Use AWS MCP to audit S3 buckets and generate Terraform fixes.

Why it teaches Cloud Ops: Kiro becomes an infra reviewer with live state access.

Success criteria:

• Generated Terraform closes at least one real misconfiguration.

---

Real World Outcome

You’ll configure the AWS MCP server so Kiro can audit your cloud infrastructure, identify security misconfigurations (public S3 buckets, overly permissive IAM policies), and generate Terraform code to remediate them—turning Kiro into an automated security auditor.

Configuration (.kiro/settings/mcp.json):

{
  "mcpServers": {
    "aws": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-aws"],
      "env": {
        "AWS_PROFILE": "production-readonly",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

When you ask Kiro to audit infrastructure:

$ kiro chat

You: "Audit all S3 buckets for public access and generate Terraform fixes"

Kiro: [Tool: aws/list_s3_buckets]
Found 47 S3 buckets. Checking public access settings...

[Tool: aws/get_bucket_policy] (for each bucket)
[Tool: aws/get_bucket_acl]

**Security Audit Results:**

🚨 **Critical Issues Found (3 buckets):**

1. **app-logs-production** (public read access)
   - Bucket Policy: Allows s3:GetObject for Principal: "*"
   - Risk: Sensitive application logs exposed to internet
   - Created: 2023-05-12
   - Size: 2.4 TB

2. **user-uploads-staging** (public write access)
   - ACL: Grant WRITE to AllUsers
   - Risk: Anyone can upload files (potential malware hosting)
   - Created: 2024-08-03
   - Size: 340 GB

3. **backup-configs** (public list access)
   - Bucket Policy: Allows s3:ListBucket for Principal: "*"
   - Risk: Attackers can enumerate backup file names
   - Created: 2022-11-20
   - Size: 56 GB

**Generating Terraform Fixes...**

Created: `terraform/s3-security-fixes.tf`

```hcl
# Fix for app-logs-production: Remove public access
resource "aws_s3_bucket_public_access_block" "app_logs_production" {
  bucket = "app-logs-production"

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_policy" "app_logs_production" {
  bucket = "app-logs-production"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "DenyPublicAccess"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:GetObject"
        Resource  = "arn:aws:s3:::app-logs-production/*"
        Condition = {
          StringNotEquals = {
            "aws:PrincipalOrgID" = "o-abc12345"  # Your AWS Organization ID
          }
        }
      }
    ]
  })
}

# Fix for user-uploads-staging: Remove public ACL
resource "aws_s3_bucket_acl" "user_uploads_staging" {
  bucket = "user-uploads-staging"
  acl    = "private"
}

# Fix for backup-configs: Block all public access
resource "aws_s3_bucket_public_access_block" "backup_configs" {
  bucket = "backup-configs"

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Apply with:

cd terraform/
terraform plan -out=security-fixes.tfplan
terraform apply security-fixes.tfplan

Estimated Impact:

• Fixes 3 critical security vulnerabilities
• Protects 2.8 TB of sensitive data
• Prevents potential compliance violations (GDPR, SOC 2) ```

The power: Kiro queried live AWS state, identified real security issues, and generated production-ready Terraform code to fix them.

---

The Core Question You’re Answering

“How can I continuously audit cloud infrastructure for security misconfigurations without manually reviewing every resource?”

Traditional cloud auditing requires:

1. Manually checking AWS Console
2. Writing custom scripts to query APIs
3. Remembering which settings to check
4. Manually drafting Terraform fixes

This project automates the entire workflow: Kiro becomes your infrastructure security engineer that never sleeps.

---

Concepts You Must Understand First

Stop and research these before coding:

1. AWS IAM Policies and Permissions
   • What’s the difference between identity-based and resource-based policies?
   • How do you create a read-only IAM role for infrastructure auditing?
   • What permissions are needed to list and describe S3 buckets?
   • Book Reference: “AWS Security” by Dylan Shield - Ch. 2
2. S3 Security Model
   • What’s the difference between Bucket Policies, ACLs, and Public Access Blocks?
   • How do you check if a bucket is publicly accessible?
   • What are the risks of public S3 buckets (data leaks, malware hosting)?
   • Web Reference: AWS S3 Security Best Practices
3. Terraform State Management
   • How do you import existing AWS resources into Terraform state?
   • What’s the difference between terraform plan and terraform apply?
   • How do you manage Terraform state for team collaboration (remote backends)?
   • Book Reference: “Terraform: Up & Running” by Yevgeniy Brikman - Ch. 3

---

Questions to Guide Your Design

Before implementing, think through these:

1. Audit Scope
   • Should Kiro audit all AWS regions, or just production regions?
   • What resources should be audited (S3, IAM, EC2 security groups)?
   • How do you prevent Kiro from modifying critical infrastructure?
   • Should audits run on-demand or scheduled (cron)?
2. Security Boundaries
   • What IAM permissions should the AWS MCP server have (read-only)?
   • How do you prevent Kiro from accidentally deleting resources?
   • Should Kiro be able to apply Terraform changes, or just generate code?
   • How do you audit Kiro’s own actions (CloudTrail logs)?
3. Terraform Generation
   • Should generated Terraform use modules or raw resources?
   • How do you handle resources not managed by Terraform (manual imports)?
   • What naming conventions for generated Terraform files?
   • Should Kiro check if a resource is already in Terraform state before generating?

---

Thinking Exercise

Scenario: Multi-Account Audit

Given this AWS organization structure:

Organization (o-abc12345)
├── Production Account (123456789012)
│   ├── S3 buckets (50)
│   ├── IAM roles (200)
│   └── Security groups (300)
├── Staging Account (234567890123)
│   ├── S3 buckets (30)
│   └── IAM roles (100)
└── Development Account (345678901234)
    ├── S3 buckets (20)
    └── IAM roles (50)

Questions to consider:

Cross-Account Access:

• How do you configure Kiro to assume roles in different accounts?
• Should you use AWS SSO, or cross-account IAM roles?
• What’s the minimum permission set for read-only auditing?

Audit Strategy:

# Option 1: Sequential per account
for account in prod staging dev; do
  kiro chat --prompt "Audit S3 in $account account"
done

# Option 2: Parallel with subagents
kiro chat --prompt "Audit S3 across all accounts in parallel"

Terraform State Organization:

• One Terraform state per account, or unified state?
• How do you prevent state conflicts when fixing the same resource type across accounts?

---

The Interview Questions They’ll Ask

1. “How would you design an automated cloud security auditing system that scales across hundreds of AWS accounts?”

2. “Explain the security implications of giving an AI access to your AWS environment. What guardrails would you implement?”

3. “How would you prevent an AI from generating Terraform code that accidentally deletes critical infrastructure?”

4. “Describe the difference between Terraform plan and apply, and why automation should never skip the plan step.”

5. “How would you implement approval workflows for AI-generated infrastructure changes in a regulated industry?”

6. “What strategies would you use to handle Terraform drift between generated code and manually modified resources?”

---

Hints in Layers

Hint 1: Create Read-Only AWS IAM Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:GetBucketPolicy",
        "s3:GetBucketAcl",
        "s3:GetBucketPublicAccessBlock",
        "iam:ListRoles",
        "iam:GetRole",
        "iam:GetRolePolicy"
      ],
      "Resource": "*"
    }
  ]
}

Hint 2: Configure AWS Credentials

# ~/.aws/config
[profile production-readonly]
role_arn = arn:aws:iam::123456789012:role/KiroAuditor
source_profile = default
region = us-east-1

Hint 3: Test AWS MCP Server

kiro chat

You: "List all S3 buckets in the current AWS account"

# Should return:
# - bucket-1
# - bucket-2
# - ...

Hint 4: Generate Terraform Incrementally Create a steering file (.kiro/steering/terraform-standards.md):

# Terraform Code Generation Standards

When generating Terraform:
1. Use `aws_s3_bucket_public_access_block` for blocking public access
2. Always include `depends_on` for resource dependencies
3. Add comments explaining WHY each resource is needed
4. Use variables for account IDs and region names

---

Books That Will Help

Topic	Book	Chapter
AWS Security	“AWS Security” by Dylan Shield	Ch. 2-4 (IAM, S3 Security)
Terraform	“Terraform: Up & Running” by Yevgeniy Brikman	Ch. 3-5
Infrastructure as Code	“Infrastructure as Code” by Kief Morris	Ch. 7 (Security)
Cloud Security	“Cloud Security and Privacy” by Tim Mather et al.	Ch. 4 (Storage Security)

---

Common Pitfalls & Debugging

Problem 1: “AWS MCP server fails with ‘AccessDenied’“

• Why: IAM role lacks required permissions
• Fix: Add s3:ListAllMyBuckets to the role policy
• Quick test: aws s3 ls --profile production-readonly

Problem 2: “Terraform plan shows unrelated changes”

• Why: Kiro is unaware of existing Terraform state
• Fix: Run terraform import for existing resources before generating fixes
• Quick test: terraform state list shows imported resources

Problem 3: “Generated Terraform uses hardcoded account IDs”

• Why: Kiro doesn’t know to parameterize account-specific values
• Fix: Add steering rule: “Use data.aws_caller_identity.current.account_id”
• Quick test: Generated code includes data "aws_caller_identity"

Problem 4: “Kiro recommends changes that would break production”

• Why: Kiro doesn’t understand resource dependencies
• Fix: Use read-only mode, require manual review before applying
• Quick test: Only generate code, never auto-apply

---

Definition of Done

• Created read-only AWS IAM role with S3 and IAM describe permissions
• Configured AWS MCP server in .kiro/settings/mcp.json with correct profile
• Verified Kiro can list S3 buckets and read bucket policies
• Kiro identified at least one real security misconfiguration
• Generated Terraform code that passes terraform validate
• Terraform plan shows expected changes (no unintended modifications)
• Documented the audit workflow in README
• Created steering file with Terraform generation standards

---