AWS with Terraform (Day 21)

Day 21 – AWS Policy & Governance as Code with Terraform

As AWS environments scale, manual security checks and ad‑hoc governance simply don’t work. The only sustainable way is to define policy and governance as code — repeatable, auditable, and automated.

Today marks Day 21 of my continuous DevOps learning journey. While actively searching for a DevOps role, managing home responsibilities, I’m still pushing myself to learn and document real‑world cloud security practices.

This post covers how I implemented AWS policy and governance using Terraform, combining preventive controls (IAM) and detective controls (AWS Config) — the same patterns used in production environments.

Policy vs Governance (Clear Difference)

Policy – Preventive Controls

Policies enforce rules at request time. If a request violates the rule, it simply fails.

Examples:

  • Deny delete actions if MFA is not enabled

  • Block S3 uploads over HTTP

  • Enforce mandatory tags on resource creation

These controls stop risky actions before damage happens.

Governance – Detective Controls

Governance focuses on visibility, audit, and compliance.

AWS Config:

  • Records resource state changes

  • Evaluates rules after creation or modification

  • Marks resources as compliant or non‑compliant

  • Maintains history for audits and investigations

Both are essential. One prevents mistakes, the other ensures accountability.

What This Terraform Project Creates

This setup is fully automated using Terraform and includes:

  • Secure S3 audit bucket for AWS Config logs

  • Bucket policy enforcing encrypted transport

  • IAM demo user and AWS Config service role

  • Preventive IAM policies

    • MFA‑required deletes

    • Encrypted uploads only

    • Mandatory tagging enforcement

  • AWS Config recorder & delivery channel

  • Managed AWS Config rules for compliance checks

Everything is reproducible, version‑controlled, and auditable.

S3 Audit Bucket – Production‑Grade Setup

Audit logs must be protected like critical data. The bucket configuration includes:

  • Globally unique name using prefix + random suffix

  • Versioning enabled to preserve history

  • Server‑side encryption (AES‑256; KMS optional)

  • Block public access at account and bucket level

  • Strict bucket policy for AWS Config

Example: Deny Insecure Transport

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::your-audit-bucket/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

This ensures no logs are written over HTTP, even by mistake.

IAM Policies – Preventive Security Controls

These customer‑managed IAM policies block dangerous actions before execution:

1. MFA‑Protected Deletes

  • Deny delete actions if aws:MultiFactorAuthPresent is false

2. Encrypted Upload Enforcement

  • Deny s3:PutObject if aws:SecureTransport is false

3. Mandatory Tagging

  • Deny resource creation when required tags like environment or owner are missing

These policies can be attached to users, groups, or roles depending on the access model.

Common IAM Pitfalls (Real‑World Lessons)

Things that often break policies:

  •  Wrong action names (DeleteObject ≠ DeleteBucket)

  •  Policy not attached to the actual principal

  •  Action performed via a different role or service

  •  Incorrect condition keys or values

IAM Policy Simulator and CloudTrail are essential for debugging.

AWS Config – Detective Governance

Terraform provisions:

  • Config Recorder (all supported resource types)

  • Delivery Channel pointing to encrypted S3 bucket

  • Managed Rules, including:

    • S3 public write prohibited

    • S3 server‑side encryption enabled

    • EBS volume encryption enabled

    • Required tags present

    • Root account MFA enabled

AWS Config doesn’t block — it detects, reports, and records evidence.

Prevention vs Detection – Defense in Depth

  • IAM Policies → Stop bad actions immediately

  • AWS Config → Detect, report, and audit continuously

Using both together is how mature cloud security is built.

Testing & Validation Workflow

After terraform apply:

  1. Verify S3 bucket encryption, versioning, and public access block

  2. Confirm IAM policies are attached correctly

  3. Ensure AWS Config recorder is running

  4. Create intentionally non‑compliant resources

  5. Wait for AWS Config evaluation results

If a Deny Didn’t Work:

  • Check CloudTrail (who did what?)

  • Confirm policy attachment

  • Validate action names

  • Test with IAM Policy Simulator

  • Review resource‑based policies

Best Practices I’m Following

  • Least privilege everywhere

  • Preventive + detective controls together

  • Centralized, encrypted audit logs

  • Terraform‑driven security

  • Testing in non‑production first

  • Continuous learning despite pressure

Personal Note

I’m currently actively looking for a DevOps / Cloud / Platform Engineer role.

While managing family responsibilities and I’m still:

  • Learning advanced AWS, Terraform, and DevOps tooling

  • Building real, production‑style projects

  • Writing detailed technical blogs like this

If you or your team:

  • Need a hands‑on DevOps engineer

  • Value real‑world AWS + Terraform experience

  • Believe in giving driven engineers a chance

📩 Please reach out or refer me. Even a conversation helps.

Conclusion

Terraform makes it possible to codify security and governance the same way we codify infrastructure.

  • IAM policies prevent risky actions in real time

  • AWS Config provides continuous compliance and audit trails

Together, they form a strong foundation for scalable cloud governance.

Day 21 completed. Still learning. Still pushing. Still looking forward.

Here is the session link:



Comments

Post a Comment

Popular posts from this blog

AWS with Terraform (Day 01)

Image
  Terraform Fundamentals – Day 01 (My Learning Notes as a DevOps Engineer) Today I wrapped up Day-01 of my Terraform with AWS series, and even with my DevOps background, this session helped me tighten my fundamentals and rethink how I approach cloud provisioning. Terraform is something I’ve used before, but today was more about understanding why IaC matters at scale and why Terraform continues to dominate in real-world DevOps ecosystems. Understanding Infrastructure as Code (IaC) As a DevOps engineer, IaC is not new to me. But today’s session broke it down in a way that clarified its real value. IaC = Infrastructure represented as code. Instead of building resources manually through AWS/Azure/GCP consoles, we define everything in .tf files. This ensures our setup is predictable, repeatable, and version-controlled. What I liked most is how clearly the contrast was shown: Cloud-Agnostic Tools (Terraform / Pulumi) Work across AWS, Azure, GCP, Kubernetes, GitHub, etc. ...
Read more

AWS with Terraform (Day 27)

Image
Automating AWS Infrastructure Using Terraform and GitHub Actions Infrastructure automation is where DevOps truly becomes real. Writing Terraform code is only half the story—the real value comes when infrastructure changes are version-controlled, reviewed, scanned, approved, and applied automatically . On Day 27 of my DevOps journey, I implemented a production-grade CI/CD pipeline to automate AWS infrastructure using Terraform and GitHub Actions , following best practices used in real-world teams. This blog walks through the architecture, workflow design, safety controls, and lessons learned . Why Automate Terraform with CI/CD? Running Terraform manually from a laptop works for learning, but it quickly breaks down in team and production environments: Local state files are risky and hard to share Credentials scattered across machines No standardized reviews or approvals No security or policy checks before apply No clear audit trail By integrating Terraform with G...
Read more

AWS with Terraform (Day 02)

Image
  AWS with Terraform – Day 02 Deep Dive into Providers, Versioning & the Real “Bridge” Between Code and Cloud Today’s session took me from simply writing Terraform code to actually understanding the engine behind it — the Provider layer . And honestly, once this clicks, Terraform stops feeling like just a tool and starts feeling like a real engineering system. Here’s what I learned and how I’ve started applying it. Providers: The Plugin That Makes Terraform Real The simplest way I now understand it: Terraform writes the story. Providers translate it into cloud actions. Before today, I treated the provider block as just two lines of mandatory code. Now I see it as the translator that turns HCL into actual AWS API calls . Example: I write: resource "aws_s3_bucket" "demo" { bucket = "my-app-demo" } The AWS provider turns that into the exact S3 API request. This layer saves us from manually hitting APIs, building payloads, or juggling ...
Read more