Lab 04 — AWS Landing Zone: Attack Paths, Guardrails, and Recovery

Difficulty: 5/5 | Provider: AWS

Pairs with the whole Phase 07 WARMUP and the HITCHHIKERS-GUIDE ("Build the Landing Zone as a Security Product", "Provider Attack-Path Drills"). Build the offline evaluator first; reproduce only in a dedicated sandbox AWS Organization.

Why This Lab Exists (Purpose & Goal)

A "landing zone" is the secure foundation an entire cloud estate is built on — the account structure, guardrails, identity model, logging, and network baseline that every workload inherits. Get it right and thousands of resources are safe by default; get it wrong and every workload inherits the flaw. The goal of this lab is to make you build, attack, and defend a real AWS landing zone end to end: an offline policy evaluator for the invariants, plus the hands-on break/fix/recover cycle in a sandbox Organization.

The Concept, In the Weeds

The attack story is concrete and realistic: a compromised CI principal that can pass a powerful role, reach the instance metadata service (IMDS), decrypt data, disable logging, or publish storage. Each seeded failure is a real-world misconfiguration with a real breach behind it:

  • wildcard administration, unrestricted iam:PassRole — the escalation edges from Lab 01, now in AWS terms (the most common cloud-privilege-escalation path).
  • third-party trust without ExternalId — a confused-deputy edge a vendor (or attacker) can abuse.
  • IMDSv1 — the SSRF-to-credentials pivot that caused the Capital One breach; IMDSv2's session requirement closes it.
  • public S3 — the canonical cloud data-exposure mechanism.
  • KMS admin + decrypt on one identity — separation-of-duties failure that makes encryption moot.
  • account-local CloudTrail — an attacker who compromises the account can also delete the logs; centralize and protect them.
  • EKS pods inheriting node credentials — the Kubernetes-to-cloud credential pivot.

The defenses compose into defense in depth: Organizations with separate accounts; SCPs as maximum-permission guardrails (a ceiling, not a grant — a critical distinction); short-lived federated workload identity with constrained trust policies; IMDSv2 and explicit egress; KMS role separation; centralized, independently-protected trails; and detections for the dangerous changes.

Why This Matters for Protecting the Company

The landing zone is the blast-radius control for the entire AWS footprint. A flaw here — a too-broad SCP exemption, a missing public-access block, a centralizable-but-not-centralized trail — is inherited by every account and workload, so a single compromised CI credential can cascade to account takeover and silent log deletion. When you can build a landing zone as a security product (guardrails, identity, logging, recovery) and prove its invariants both offline and in a live account, you are protecting the foundation everything else stands on — and you can answer the leaked-credential incident with confidence because the guardrails bounded what the attacker could reach.

Run

LAB_MODULE=solution pytest -q

Break and Prove

Seed one failure at a time in insecure.tf: wildcard administration, unrestricted iam:PassRole, third-party trust without ExternalId, IMDSv1, public S3, KMS admin + decrypt, account-local CloudTrail, and EKS pods inheriting node credentials. Prove only the minimum path with IAM Access Analyzer, policy simulation, Config/Security Hub findings, CloudTrail, and synthetic canary data.

Fix and Defend in Depth

  1. Organizations with security, log-archive, shared-services, and workload accounts.
  2. SCPs as maximum-permission guardrails — not grants.
  3. Federate people; short-lived workload identity; constrained trust policies; review transitive AssumeRole + PassRole paths (Lab 01).
  4. Require IMDSv2, private endpoints, explicit egress, account-level S3 public-access blocks, and resource policies constrained by organization and endpoint.
  5. Separate KMS administrators from users; centralize organization trails and protect the destination with retention and independent access.
  6. Detect policy changes, trail stops, anomalous role assumption, public resources, KMS disable, and EKS credential anomalies. Exercise credential revocation and break glass.

Exit Evidence

Threat model, account diagram, normalized policy export, failing and passing evaluator output, CloudTrail event IDs, detection fixtures, teardown log, cost report, and an executive residual-risk memo. Never run against an employer or customer organization without written authorization.

Validation — What You Should Be Able to Do Now

  • Design a secure AWS landing zone (Organizations, SCP guardrails, federated identity, centralized protected logging, network baseline) and explain why each piece bounds blast radius.
  • Explain why an SCP is a ceiling, not a grant; why IMDSv2 matters; why trails must be centralized.
  • Trace and cut a CI-principal escalation path, and prove old access fails after revocation.

The Broader Perspective

This lab is where the abstract Phase 07 concepts become a concrete, defensible foundation — and it teaches the staff-level truth that security is mostly decided at the foundation, by defaults that every workload inherits. A good landing zone makes the secure path automatic; a bad one makes every team re-make the same mistakes. The same insight applies to paved roads in the SDLC (Phase 03) and to secure-by-default service templates: invest in the foundation and you reduce a class of risk across the whole organization, which is far higher leverage than fixing individual workloads. The AWS specifics transfer as patterns — the GCP and Azure labs (05, 06) apply the identical reasoning in each provider's model.

Interview Angle

  • "Design a secure cloud landing zone." — Org hierarchy with org-level guardrails even admins can't exceed; federated IdP + MFA, no local users, least-priv custom roles; separated accounts per env/ sensitivity; network zones + private endpoints + controlled egress; centralized tamper-resistant logging; KMS + managed secrets; org-wide public-storage deny; budgets; tested break-glass. All as reviewed IaC with policy-as-code in CI.

References

  • Phase 07 WARMUP; AWS Well-Architected Security Pillar; the Capital One SSRF post-mortem.
  • IAM Access Analyzer, Service Control Policies, CloudTrail, Security Hub documentation.