Frontend Labs
⋯

Part 10 — Capstone projects

Five integration projects, each pulling together multiple Parts of this guide into one coherent system — not a repeat of any single Part's hands-on lab, but the cross-cutting work that only shows up when cloud, containers, distributed services, web exploitation, data protection, and detection all have to work together against the same target. Do them in order; each builds on artifacts from the last. Budget one to two weeks each.

   ~/sec-lab/adv/
     projects/
       p1-cloudnative/   p2-authz/   p3-webchain/   p4-intrusion/
       p5-dataprod/
     reports/   (you already have eight from Parts 1-9's hands-on chapters)

Chapter 64 — Project 1: cloud-native SecureShop — model, build, attack, defend

Brief

Take SecureShop from a Part-by-Part lab exercise to one real, deployed, multi-account, Kubernetes-hosted system: model its full attack-path graph across cloud AND cluster together (not separately, as Parts 1/2/4 did in isolation), build it with a supply-chain-hardened pipeline, attack it end to end with a chain that crosses the cloud/cluster boundary, then harden and prove every path closed with the same graphing tools used offensively.

Tasks

   1. MODEL (Part 1 Ch 1, Part 2, Part 4)
      [ ] One combined attack-path graph spanning BOTH the cloud identity
          plane (IAM roles, KMS keys, S3 buckets) AND the Kubernetes
          cluster (ServiceAccounts, RBAC, admission policy) as a SINGLE
          graph, not two separate ones -- the edges that CROSS the
          boundary (IRSA/Workload Identity, node instance roles reachable
          from pods, Part 4 Ch 20) are exactly the ones most tools model
          separately and therefore miss.
      [ ] Identify the top 3 cross-boundary chokepoints.

   2. BUILD (Part 2 Ch 7, Part 3, Part 4)
      [ ] The multi-account structure (management/security/log-archive/
          shared-services/workloads) as IaC, with the org-wide SCP
          guardrails from Part 2 Ch 7.
      [ ] The supply-chain-hardened pipeline from Part 3 Ch 14, producing
          signed, provenance-attested images.
      [ ] An EKS/GKE cluster with the full Part 4 hardening baseline:
          PSA restricted, admission policy verifying signatures,
          default-deny NetworkPolicy, workload identity with pinned
          trust, runtime detection (Falco/Tetragon).

   3. ATTACK (cross-boundary chain -- this is the point of the project)
      [ ] Walk a chain that starts in the CLUSTER and ends in the CLOUD
          IDENTITY PLANE, or vice versa -- e.g.: an RCE in a pod (Part 6)
          -> RBAC escalation to a more-privileged ServiceAccount (Part 4
          Ch 17) -> that SA's IRSA-bound IAM role reaches an
          over-permissioned S3 bucket (Part 2) -> cross-tenant data.
      [ ] Document every hop with the tool that finds it (KubeHound for
          the cluster half, PMapper/CloudFox for the cloud half) and note
          where the CROSSING itself (the workload-identity trust binding)
          was the actual chokepoint.

   4. DEFEND
      [ ] Close every edge, cheapest chokepoint first (Part 1's
          prioritisation), re-testing after each with the SAME tools used
          offensively.
      [ ] Confirm BOTH KubeHound and PMapper/CloudFox independently show
          no remaining path across the boundary.

   5. DETECT (Part 8)
      [ ] Build at least 2 detections specifically for the CROSS-BOUNDARY
          steps of your chain (Part 8 Ch 54's method, applied here).
          Live-validate by re-running the (now-broken) attack.

Deliverable

~/sec-lab/adv/projects/p1-cloudnative/report.md: the combined graph (before/after), the cross-boundary attack chain with evidence at every hop, the IaC/pipeline/cluster configuration, the fixes with proving re-tests from both tool families, and the two cross-boundary detections with live-validation evidence.

Definition of done

  • One combined cloud+cluster attack-path graph, not two separate ones.
  • A walked chain crossing the cloud/cluster boundary in at least one direction, fully documented.
  • Every edge closed; both KubeHound and PMapper/CloudFox confirm no remaining path.
  • Two detections specifically targeting the cross-boundary steps, live-validated.

Rubric (/100)

   Combined graph + identified cross-boundary chokepoints ... 20
   Build: multi-account + pipeline + hardened cluster ....... 20
   Cross-boundary attack chain, documented .................. 25
   Every edge closed, both tool families confirm clean ...... 20
   Cross-boundary detections, live-validated ................ 10
   Report .................................................... 5

Further reading

  • Revisit Part 1 Ch 1, Part 2 Ch 6/10, Part 4 Ch 17/20/22 together — this project is their synthesis.
  • Tool: KubeHound's documentation on integrating cloud-identity edges into its graph model (where supported) — the direct tooling answer to "model both together."

Generated from real-life-security-guide-v1.md · 8 Oct 2026 16:36