Infrastructure Security: IaC and Cloud

Use AI to review Terraform configurations, Kubernetes manifests, and cloud settings for security misconfigurations before they hit production.

Premium Course Content

This lesson is part of a premium course. Upgrade to Pro to unlock all premium courses and content.

Access all premium courses
1000+ AI skill templates included
New content added weekly

← Back to course overview

80% of cloud breaches stem from misconfigurations, not sophisticated attacks. A public S3 bucket, an overpermissive IAM role, or a Kubernetes pod running as root — these are the real threats. AI catches them before deployment.

🔄 Quick Recall: In the previous lesson, you learned AI-powered vulnerability scanning and triage for code and dependencies. Infrastructure security is the next layer — ensuring the platform your code runs on is also hardened.

Terraform Security Review

AI-Assisted Terraform Review

Review this Terraform configuration for security issues:

[Paste Terraform code]

Check against:
1. CIS AWS Foundations Benchmark
2. AWS Well-Architected Security Pillar
3. OWASP Cloud Security best practices

For each finding:
- Severity: Critical / High / Medium / Low
- What's wrong and why it's a risk
- The specific fix (show the corrected Terraform)
- CIS/benchmark reference number

Common Terraform Security Fixes

I have these Terraform security findings. Generate the fixes:

1. S3 bucket without encryption at rest
2. Security group allowing 0.0.0.0/0 on port 22
3. RDS instance without encryption
4. IAM policy using wildcard (*) actions
5. CloudTrail not enabled in all regions

For each, show:
- The insecure Terraform (what I have)
- The secure Terraform (what I need)
- One-line explanation of why this matters

✅ Quick Check: You review an IAM policy that grants "Action": "s3:*" on "Resource": "*". AI flags this as overly permissive. The developer says they need S3 access for their Lambda function. What’s the principle AI is enforcing, and what’s the fix? (Answer: Principle of least privilege. The fix: specify exactly which S3 actions the Lambda needs (e.g., s3:GetObject, s3:PutObject) and which bucket (arn:aws:s3:::my-specific-bucket/*). AI generates the scoped-down policy: same functionality, 95% less attack surface.)

Kubernetes Security

Manifest Security Review

Review this Kubernetes deployment for security best practices:

[Paste YAML manifest]

Check for:
1. Security context (non-root, read-only filesystem, capabilities)
2. Resource limits (CPU, memory — prevent resource abuse)
3. Network policies (pod-to-pod communication restrictions)
4. Image security (pinned versions, trusted registries)
5. Secret management (no hardcoded secrets in manifests)
6. Pod disruption budgets and health probes

For each finding, show the corrected YAML.

Kubernetes Hardening Checklist

Generate a Kubernetes cluster hardening checklist for production:

Cluster: EKS on AWS (Kubernetes 1.29)
Workloads: 15 microservices, internet-facing API gateway
Compliance: SOC 2, need audit trail

Categories:
- Cluster-level controls (RBAC, audit logging, network policies)
- Node-level controls (OS hardening, runtime security)
- Workload-level controls (pod security, resource limits)
- Network controls (ingress/egress policies, service mesh)
- Secret management (external secrets operator, encryption)
- Monitoring and alerting (runtime anomaly detection)

Format as a checklist with implementation notes.

Cloud Security Posture

AWS Security Audit

Audit this AWS account configuration for security issues:

Account details:
- 3 VPCs (prod, staging, dev)
- 50 IAM users, 12 IAM roles
- S3: 30 buckets
- RDS: 5 instances
- Lambda: 40 functions
- CloudFront: 3 distributions

Check:
1. IAM: MFA enforcement, access key rotation, unused credentials
2. S3: Public access, encryption, versioning, access logging
3. Network: Security group rules, NACLs, VPC flow logs
4. Data: RDS encryption, backup retention, access controls
5. Logging: CloudTrail, Config, GuardDuty status
6. Cost of NOT fixing each finding (risk quantification)

IaC Scanning Tools

Tool	IaC Support	AI Feature	Free
Checkov	Terraform, K8s, CloudFormation	1,000+ built-in policies	Open source
tfsec	Terraform	Fast scanning with custom rules	Open source
Kics	Multi-IaC	Broad framework support	Open source
Bridgecrew	Multi-IaC	AI fix suggestions, drift detection	Free tier
Spacelift	Terraform, Pulumi	AI policy enforcement in CI/CD	Free tier

Practice Exercise

Take a Terraform module from your project and run it through AI security review
Audit a Kubernetes deployment manifest for the 6 security categories above
Generate a least-privilege IAM policy for one of your services using AI

Key Takeaways

80% of cloud breaches come from misconfigurations — AI catches them before deployment
Principle of least privilege is the most impactful security practice — AI generates scoped-down IAM policies
Terraform and Kubernetes reviews should happen in PRs, not after deployment — shift left
Different environments need different security levels — AI generates both production-hardened and dev-friendly configs
Open-source tools (Checkov, tfsec) provide strong baseline scanning; AI adds contextual analysis

Up Next

In the next lesson, you’ll learn to secure your CI/CD pipeline — the critical path from code to production where security gates prevent vulnerable code from deploying.

Knowledge Check

1. Your Terraform config creates an S3 bucket with `acl = "public-read"`. AI flags this as a critical misconfiguration. But the bucket serves static website assets and NEEDS to be public. Is AI wrong?

Yes — AI doesn't understand the use case AI is right to flag it, but context matters. The correct approach: acknowledge the finding, document WHY this bucket is intentionally public, and add compensating controls (no sensitive data, CloudFront distribution, access logging). Then suppress the finding with an inline comment: `# SECURITY: Intentionally public — static assets only` Make the bucket private — public S3 is always wrong

2. AI reviews your Kubernetes deployment manifest and recommends adding resource limits, a non-root security context, and read-only root filesystem. Your dev team says these restrictions break their debugging workflow. What's the right response?

Skip security for dev environments Implement the security controls in production but provide a documented override for dev. AI can generate both: a production-hardened manifest AND a dev variant with clear comments marking each security relaxation. This way production is secure and developers can debug effectively Apply all restrictions everywhere — no exceptions

3. You have 200 Terraform files across 15 microservices. A new CIS Benchmark is released. How do you audit all 200 files against the new benchmark?

Manually read all 200 files Use AI to parse the new CIS requirements, then scan all Terraform files against them. AI generates a compliance report: which files pass, which fail, and a prioritized fix list. Tools like Checkov or tfsec do this automatically, but you can also paste Terraform configs into AI with the specific CIS requirements for targeted review Only audit new files going forward

Answer all questions to check

Complete the quiz above first