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."