0.6 The running example grows up

G1 used SecureShop: shop.securesh.op (web + API) -> orders-api -> PostgreSQL, plus admin.securesh.op. This guide promotes it to a cloud-native, multi-tenant SaaS, and each Part adds a layer.

   SecureShop, cloud-native (the shape we'll secure through this guide):

     Route53 / Cloud DNS
        |
     CloudFront / Cloud CDN  --(WAF)-->  ALB / Gateway API
        |
     EKS / GKE cluster  (multi-AZ)
        namespace: edge      -> web (Next.js), BFF
        namespace: core      -> orders-api, catalog-api, payments-api (gRPC)
        namespace: platform  -> SPIRE, OPA/OpenFGA, cert-manager, external-dns
        namespace: data      -> read models, cache (Redis), search (OpenSearch)
        service mesh: mTLS everywhere (SPIFFE identities)
        |
     Managed data:
        Aurora/Cloud SQL PostgreSQL  (per-tenant row-level security)
        S3 / GCS  (object store: invoices, exports -- envelope-encrypted)
        KMS  (key hierarchy: org CMK -> per-tenant DEKs)
        Secrets Manager / Secret Manager  (dynamic DB creds)
        Kafka / PubSub  (order events, signed)
        |
     Identity:
        customers  -> OIDC (Auth0/Cognito/Keycloak), passkeys
        employees  -> SSO IdP (Okta/Entra) -> SAML/OIDC to internal tools
        workloads  -> SPIFFE SVIDs, IRSA/Workload Identity for cloud APIs
        |
     Pipeline:
        GitHub -> Actions (OIDC to cloud, no static keys) -> build ->
        sign (cosign) + SBOM + provenance -> registry -> admission
        controller verifies signature -> deploy (Argo CD)
        |
     Multi-account / multi-project:
        management (org, SCPs, logging) | security (GuardDuty, log archive,
        IR tooling) | shared-services (CI, registry) | prod | staging | dev
        | sandbox (this is where you break things)

   Tenancy: SecureShop is SaaS. Each customer ("tenant") shares the cluster
   and database but MUST be isolated: no tenant can read another's orders,
   invoices, events, or search index. Proving that isolation is a running
   thread (Ch 27, Project 2).

Chapter 4 will produce the full threat model. Keep a page where you record your instinct, now, for four questions — we'll revisit them:

   1. An attacker gets a shell in the `web` pod. What can they reach, and
      how would you know?
   2. A CI token leaks from a public repo. What can it do, and for how long?
   3. Tenant A's admin tries to read Tenant B's invoices via the API. What
      stops them, at how many independent layers?
   4. You must delete a customer's data on request. List every place a copy
      exists.