Warmup Guide — Cloud and Kubernetes Security from Identity Outward

Zero-to-expert primer for Phase 07. It builds cloud security from first principles starting where the real boundary is — identity and the control plane — then networking, data/KMS, the Kubernetes security model (RBAC, admission, Pod Security, network policy, workload identity), supply chain, detection/IR, infrastructure-as-code and policy-as-code, and the engineering reading of compliance (FedRAMP/PCI/HIPAA/SOC 2/ISO 27001). Assumes Phases 02, 03, 06. By the end you should be able to trace access from an identity provider to a resource policy, explain why a Kubernetes namespace is not a tenant boundary, rotate a compromised credential and prove old access fails, and turn a compliance sentence into a tested control with evidence.

Table of Contents

Chapter 1: In the Cloud, Identity Is the Perimeter

Zero background. On-premises, security leaned on the network perimeter — a firewall between "inside" (trusted) and "outside" (untrusted). In the cloud there is no inside: every resource is an API endpoint reachable over the internet, and access is decided by identity and policy, not by which network you're on. The famous phrase is "identity is the new perimeter." This is the most important reframe of the whole phase.

Why. A storage bucket, a database, a Kubernetes API, a secret — each is governed by an IAM policy that asks "which principal may do what action on what resource, under what conditions?" An attacker who obtains a credential (a leaked key, a token from a compromised workload, an over-permissioned role) doesn't need to "get inside the network" — they are an authorized identity. Therefore the highest-leverage cloud security work is identity hygiene: least privilege, no long-lived keys, federation, and understanding the transitive privilege graph (Chapter 4).

The control plane vs the data plane. Every cloud has a control plane (the APIs that create and configure resources — IAM, networking, KMS) and a data plane (the resources doing work). Control-plane compromise is catastrophic because it can reconfigure everything, including disabling your logging. Protecting the control plane (MFA, federation, no public exposure, separation of duties, break-glass) is priority one.

Misconception to kill now. "It's in a private VPC, so it's protected." Network placement is one layer, but the resource is still governed by IAM, and many control-plane APIs are reachable regardless of VPC. Identity policy is the decisive control.

Chapter 2: The Shared Responsibility Model

The division. The cloud provider secures the cloud (physical, hypervisor, managed-service internals); you secure what you put in the cloud (your IAM, data, configuration, code, network rules). The line moves by service type:

  • IaaS (VMs): you own the OS, patching, and almost everything above the hypervisor.
  • PaaS / managed services (managed DB, serverless): the provider owns more of the stack; you own access policy, data, and configuration.
  • SaaS: you own identity, data governance, and configuration; the provider owns the app.

Why it matters operationally. Most cloud breaches are customer-side misconfigurations (public buckets, over-permissioned roles, exposed control planes) — i.e., on your side of the line. "The provider is secure" is true and irrelevant to the bugs you'll actually face.

Misconception to kill now. "We're on AWS/GCP/Azure, so security is handled." The provider secures their layer; the breach surface you own — identity, config, data — is exactly where incidents happen.

Chapter 3: IAM — Policy Evaluation and Least Privilege

The model. IAM (Identity and Access Management) decides each request by evaluating policy. Conceptually a request is allowed if there is an applicable allow and no overriding deny, across the layers a provider supports (organization-level guardrails, resource hierarchy, resource/identity policies, conditions). The pieces:

  • Principals: human users (ideally federated from an IdP, not local accounts), groups, and service accounts / roles for workloads.
  • Permissions/roles: the actions a principal may perform. Wildcards (*) are the enemy of least privilege — s3:* on * is a blank check.
  • Resource hierarchy: org → folders/OUs → accounts/projects → resources, with policy inheriting downward; guardrails (SCPs/org policies) set hard ceilings even an account admin can't exceed.
  • Conditions: restrict by source, MFA, time, tags — the cloud analog of Phase 02's context.

Least privilege and separation of duties. Grant the minimum actions on the minimum resources; split powerful duties so no single identity can both act and cover its tracks (e.g. the deployer is not the auditor). Break-glass: a tightly controlled, heavily logged emergency identity used only when normal paths fail — and tested in a drill.

Access reviews. Privilege accretes; periodic review removes unused grants. "Permission inventory → custom least-privilege roles → access review → break-glass drill" is the Week-2 lab arc.

Misconception to kill now. "Managed/AWS-managed policies are fine." Many built-in roles are broad for convenience; least privilege usually means custom roles scoped to your actual usage.

Chapter 4: Attack Paths — Identity as a Graph

The key insight (the flagship lab). IAM is not a flat list of grants — it's a graph, and attackers think in paths. A principal with one innocuous-looking permission can often reach much more by chaining:

  • Privilege escalation by permission: iam:PassRole + lambda:CreateFunction lets a low-priv user run code as a high-priv role. iam:CreatePolicyVersion lets you grant yourself anything. Dozens of such "escalation primitives" exist per cloud.
  • Trust relationships: role A can be assumed by principal B (cross-account sts:AssumeRole, workload-identity federation); a chain of assume-role edges is a path.
  • Resource-based reach: a service account attached to a compute instance + the instance metadata service = anyone with code execution on that instance gets the SA's tokens.

The Cloud IAM Attack-Path Analyzer lab makes you model identities, permissions, and trust as a graph and find the transitive paths to sensitive resources — because "this role looks fine in isolation" misses the three-hop chain to admin. The acceptance bar: no unexplained wildcard privilege and no unintended trust path.

Misconception to kill now. "Each role is least-privilege, so we're fine." Least privilege per role doesn't prevent composition into a privileged path. You must analyze the graph, not the nodes.

Chapter 5: Workload Identity and the Death of Long-Lived Keys

The problem with long-lived keys. A static access key in code, CI, an image, or a developer's laptop is a credential that never expires and is trivially exfiltrated — the single most common cloud breach root cause. The Phase 07 hard rule: no long-lived cloud keys in code, CI, images, or developer files.

Workload identity — the fix. Instead of handing a workload a stored key, the platform attests the workload's identity and issues short-lived credentials on demand:

  • Cloud-native: attach a role/service account to the compute (EC2 instance role, GKE/EKS/AKS workload identity, Azure managed identity); the workload fetches short-lived tokens from a metadata endpoint — no secret to leak. (This is why protecting/denying the metadata endpoint from untrusted code, Phase 06, is critical.)
  • Federation / OIDC: CI systems (e.g. GitHub Actions) present an OIDC token the cloud trusts to mint short-lived credentials — zero stored secrets. This is the modern answer to "leaked CI credentials."

Comparing approaches (a README question): instance/pod identity vs OIDC federation vs SPIFFE/ service-mesh identity — all replace static secrets with attested, short-lived, audience-scoped credentials; they differ in who attests and how the token is delivered.

Misconception to kill now. "We rotate our keys every 90 days." Rotation reduces exposure window but a stored key is still leakable for up to 90 days. Workload identity removes the stored secret entirely — strictly better.

Chapter 6: Network Architecture and Zero Trust

Segmentation still matters (defense in depth), even though identity is the perimeter. Standard zones: public (internet-facing ingress, WAF, load balancer), private (application workloads, no public IP), data (databases reachable only from app tier), and admin (management, tightly restricted). Private endpoints keep traffic to managed services off the public internet; controlled egress (Phase 06's lesson) prevents data exfiltration and metadata/SSRF abuse.

Zero trust — the principle. Don't trust a request because of its network location; authenticate and authorize every request based on identity and device/context. In practice: mTLS service identity (a service mesh issues per-workload certificates so services prove who they are to each other — Phase 02 mTLS at fleet scale), per-request authorization, and no implicit "internal network = trusted."

Misconception to kill now. "It's on the internal network, so it's safe to call." Zero trust exists precisely because a foothold on the internal network shouldn't grant access — every hop authenticates.

Chapter 7: Data Security — KMS, Secrets, and Storage

KMS and envelope encryption (from Phase 02, in cloud form). A cloud KMS holds key-encryption keys in a hardened boundary; you encrypt data with per-object data keys wrapped by the KMS key (envelope encryption). Benefits: central key control, rotation without re-encrypting data, and audit of every key use. But — the recurring caveat — authorized code still sees plaintext, and "cryptographic deletion" (throw away the key to render data unrecoverable) has limits (cached plaintext, backups, replicas).

Secrets management. Use a managed secrets store (with KMS-backed encryption, access policy, and rotation) — never plaintext secrets in code, environment files committed to git, or Terraform state (Chapter 11). Access to secrets is logged and least-privileged.

Storage security — the classic breach. Object storage (S3/GCS/Blob) defaults and ACLs are a top breach source (public buckets). Enforce: no public access by default (org-level guardrail), per-object/bucket least privilege, encryption, access logging, and data classification driving controls. Backups must be tested (untested backups are a flagged mistake) and meet declared RPO/RTO (how much data you can lose / how fast you must recover).

Misconception to kill now. "It's encrypted at rest by default." Default encryption protects against disk theft, not against an over-permissioned identity that can simply read the object through the API. Authorization is still the control.

Chapter 8: The Kubernetes Security Model

What Kubernetes is, security-wise. Kubernetes is a control plane (the API server backed by etcd) that schedules pods onto nodes. Its security has several distinct layers, and conflating them is the main failure mode:

  • API authentication & RBAC. Every request to the API server is authenticated (users, service accounts) and authorized by RBAC (roles → verbs on resources). A cluster-admin service account mounted into a pod is game over — anyone who compromises that pod owns the cluster.
  • etcd holds all cluster state including secrets — it must be encrypted and access-restricted; a public/exposed API server or etcd is catastrophic.
  • Pod Security Standards (PSS). Baseline/restricted profiles that forbid dangerous pod settings (privileged, host namespaces, host path mounts, running as root) — Phase 06's container hardening as cluster policy.
  • Network policy. By default, all pods can talk to all pods (flat network). NetworkPolicy restricts pod-to-pod traffic — but only if a CNI plugin enforces it. (The Container Network Interface is the pluggable component that wires up pod networking — Calico, Cilium, etc.; a NetworkPolicy is merely a declarative object the API server stores, so if the installed CNI doesn't implement enforcement, the policy silently does nothing — a flagged mistake.)
  • Node/runtime security. The kubelet, container runtime, and the shared kernel (Phase 06) — a container escape reaches the node and its credentials.

Namespaces are NOT a tenant boundary — the load-bearing point. A Kubernetes namespace is an organizational/RBAC scope, not a strong isolation boundary: pods in different namespaces share the same nodes and kernel, the same network by default, and the same control plane. Hard multi-tenancy (untrusted tenants) needs node isolation, strong runtime sandboxing (gVisor/Kata — Phase 06), network policy, and careful RBAC — or separate clusters. (README: "assess Kubernetes tenant boundaries without assuming namespaces are sufficient.")

Misconception to kill now. "Different namespaces isolate tenants." They scope names and RBAC; they don't isolate kernel, node, or (by default) network. That assumption is a top cloud-native finding.

Chapter 9: Admission Control and Policy as Code

What admission control is. When a manifest is submitted to the Kubernetes API, admission controllers can validate or mutate it before it's persisted — the enforcement point for "no privileged pods, only signed images, resource limits required, no latest tag." This is deny-by-default (Phase 00) applied to cluster configuration.

Policy as code. Tools like OPA/Gatekeeper (policies in Rego) and Kyverno (YAML policies) let you express admission rules as tested, versioned code. The Kubernetes Admission Policy Evaluator lab makes you write policies with unit and integration tests that block all seeded unsafe manifests and permit documented safe fixtures — the same "fail on bad, green on good" discipline as the Phase 03 release gate.

Image policy and supply chain. Admission can require that images come from a private registry, pass scanning, have an SBOM, and carry a verified signature (Phase 03 — Cosign/Sigstore verification at admission). Signing without admission-time verification is theater.

Misconception to kill now. "We have Pod Security Standards, so pods are safe." PSS covers pod settings; it doesn't verify image provenance, enforce network policy, or check RBAC — admission policy plus the other layers do.

Chapter 10: Cloud Detection and Incident Response

The log sources you must wire up. Cloud gives you rich telemetry if you enable and centralize it: control-plane/API audit logs (CloudTrail/Cloud Audit Logs/Activity Log), IAM events, network flow logs, Kubernetes API audit logs, workload logs, and data-access logs. Centralize them somewhere the workload-admin can't tamper with (separation from Chapter 1's control plane).

Detection-as-code. At least 10 cloud/K8s detections, each with a fixture, an owner, a severity, and a response action (Phase 09 discipline). "Alerting without ownership" is a flagged mistake — an alert nobody owns is noise.

The cloud IR playbooks (Week 10). Build and test runbooks for the canonical cloud incidents:

  • Leaked CI/credential: identify the credential's blast radius via the IAM graph, revoke/ rotate, and prove old access fails; hunt for actions taken with it; close the leak path (move to OIDC federation).
  • Public storage exposure: lock it, assess what was accessed via access logs, notify.
  • Suspicious pod: isolate (network policy), capture, determine if it escaped to the node.
  • Key compromise: rotate the KMS key/grant, re-wrap data, audit usage.

The "prove old access fails" requirement is the heart of credential IR: rotation isn't done until you've verified the old credential is dead, not just that a new one exists.

Misconception to kill now. "We rotated the key, incident closed." Until you've revoked the old credential, confirmed it's rejected, and reviewed what it did while live, the incident is open.

Chapter 11: Infrastructure as Code and Its Own Risks

IaC — the substrate. Terraform/OpenTofu (and CloudFormation/Bicep) define infrastructure declaratively, so security review happens on the code before deploy. This enables policy as code (Checkov/tfsec/Conftest) in CI: catch a public bucket or open security group in the PR, not in production.

IaC's own attack surface (don't miss this):

  • State files contain the full resource map and often secrets in plaintext — plaintext Terraform state is a flagged mistake. Store state encrypted, with locking and least-privilege access.
  • The pipeline that applies IaC has god-mode over your cloud (Phase 03 Chapter 9) — protect it with OIDC federation, least privilege, and review.
  • Modules are third-party code (Phase 03 supply chain) — pin and review them.

CSPM/CNAPP. Cloud Security Posture Management (drift/misconfig detection across accounts) and Cloud-Native Application Protection Platforms (posture + workload + identity) are the continuous assessment layer. The IaC-scanner lab makes you write custom Terraform checks and a CI policy pack with exceptions (owner + expiry, Phase 03).

Misconception to kill now. "IaC makes us secure." IaC makes infra reviewable and repeatable; it also centralizes a high-value attack surface (state + pipeline) you must protect.

Chapter 12: Compliance as Engineering — Controls and Evidence

The reframe. Compliance frameworks are not checkbox bureaucracy to a security engineer — they are requirement specifications you translate into tested engineering controls with evidence. The frameworks, briefly:

  • SOC 2 — trust-services criteria (security, availability, confidentiality, …); an audit of whether your controls operate over a period.
  • ISO 27001 — an information security management system (ISMS) with a control catalog (Annex A).
  • PCI DSS — prescriptive controls for cardholder data environments.
  • HIPAA — safeguards for protected health information.
  • FedRAMP — NIST 800-53 controls for US-government cloud, with continuous monitoring; the most rigorous.

The engineering deliverable — the evidence chain. For each requirement, you link: requirement → implementation (the actual control) → test (proving it works) → artifact (evidence) → owner → frequency. The Compliance Control Evidence Validator lab enforces exactly this lifecycle — requirement-to-implementation-to-test-to-evidence — because scan-only compliance (a flagged mistake) produces a checkbox with no proof the control actually operates.

Translating one requirement (the interview skill). Take "PCI DSS: encrypt cardholder data in transit." Implementation: TLS 1.2+ everywhere, enforced by config/admission. Test: an automated check that rejects non-TLS endpoints. Evidence: the test result + config, owned by the platform team, run continuously. That requirement → control → test → evidence translation is the whole game.

Inherited controls. Using a compliant provider, you inherit their controls for the layers they own (Chapter 2) — but you must document the boundary and own your controls. FedRAMP makes this explicit.

Misconception to kill now. "Compliance ≠ security." Half-true: a checkbox program isn't security, but compliance done as engineering (tested controls + fresh evidence) is a strong security backbone. The failure is treating it as paperwork instead of tested controls.

Lab Walkthrough Guidance

The three core labs are provider-agnostic; the three landing-zone labs apply them per cloud:

  1. Lab 01 — Cloud IAM Attack-Path Analyzer. Model identity/permissions/trust as a graph and find transitive privilege paths (Chapter 4). No unexplained wildcard or unintended trust path.
  2. Lab 02 — Kubernetes Admission Policy Evaluator. Write tested admission policies that block unsafe manifests and pass safe fixtures (Chapters 8–9).
  3. Lab 03 — Compliance Control Evidence Validator. Enforce requirement→implementation→test→ evidence→owner→frequency (Chapter 12).
  4. Labs 04/05/06 — AWS / Google Cloud / Azure Landing Zones. Apply identity, org, data, logging, Kubernetes, and IR controls in each provider's model (deploy one fully; model the others).
pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v

Success Criteria

You are ready for Phase 08 when you can, without notes:

  1. Explain why identity, not the network, is the cloud perimeter, and why the control plane is priority one.
  2. Trace human and workload access from the identity provider to a resource policy.
  3. Find a transitive IAM privilege-escalation path through a permission/trust graph.
  4. Replace a long-lived key with workload identity / OIDC federation and explain why it's strictly better.
  5. Explain why a Kubernetes namespace is not a tenant boundary and what hard multi-tenancy needs.
  6. Write a tested admission policy that fails on unsafe manifests and passes safe ones.
  7. Rotate a compromised credential and prove old access fails.
  8. Translate one PCI/HIPAA/FedRAMP requirement into implementation, test, and evidence.

Common Mistakes

  • Deploying three clouds shallowly instead of one deeply.
  • Public control planes / API servers by default; plaintext Terraform state.
  • Cluster-admin service accounts mounted into pods; assuming namespaces isolate tenants.
  • Long-lived keys in code/CI/images; rotation instead of eliminating stored secrets.
  • Network policy without a compatible CNI enforcer (silently no-ops).
  • Scan-only compliance with no evidence chain; untested backups; alerting without ownership.

Interview Q&A

Q: Design a secure cloud landing zone. A: An org hierarchy with org-level guardrails (SCPs/org policies) that even account admins can't exceed; identity federated from a central IdP with MFA, no local users, and least-privilege custom roles; separated accounts/projects per environment and sensitivity; network zones (public/private/ data/admin) with private endpoints and controlled egress; centralized, tamper-resistant logging outside workload control; KMS-backed encryption and a managed secrets store; org-wide deny of public storage; budgets/quotas; and a tested break-glass identity. Everything as reviewed IaC with policy- as-code in CI.

Q: How do you prevent cross-tenant access in a multi-tenant K8s platform? A: Don't rely on namespaces. Use per-tenant RBAC with no cluster-admin service accounts; enforce NetworkPolicy with a real CNI enforcer (default-deny); restrict pods via Pod Security (non-root/read-only/no host namespaces); strongly isolate runtime (gVisor/Kata or dedicated node pools) for untrusted tenants; scope workload identity per tenant; and consider separate clusters for hard multi-tenancy. Add admission policy and per-tenant resource quotas, and audit the API.

Q: Respond to leaked CI credentials. A: Determine blast radius via the IAM graph (what could that credential reach transitively); revoke/ rotate it and verify old access is rejected; review audit logs for everything it did while live; contain any resources it touched; then close the root cause by moving CI to OIDC federation so no long-lived secret exists to leak. Document timeline and evidence.

Q: Compare workload identity approaches. A: All replace stored static keys with attested, short-lived, audience-scoped credentials. Cloud instance/pod identity attaches a role to compute and serves tokens via metadata (protect the metadata endpoint). OIDC federation lets an external system (CI) present a trusted OIDC token to mint short-lived creds — zero stored secrets. SPIFFE/service-mesh identity issues per-workload certs for mTLS. They differ in who attests and how the token is delivered, not in the goal: kill the long-lived secret.

Q: Map a PCI/HIPAA/FedRAMP requirement into implementation and evidence. A: Take "encrypt sensitive data in transit." Implementation: enforce TLS 1.2+ via config and an admission/policy check that rejects non-TLS endpoints. Test: an automated control that fails if any endpoint allows cleartext. Evidence: the recurring test result plus config, owned by the platform team, run continuously with a freshness check. The deliverable is requirement → control → test → evidence → owner → frequency, not a scan screenshot.

References

Provider foundations

  • AWS Well-Architected Security Pillar; Google Cloud security foundations / Architecture Framework; Azure / Microsoft Cloud Adoption Framework security.
  • CSA Cloud Controls Matrix; CIS cloud and Kubernetes benchmarks.

Kubernetes

  • Kubernetes documentation: RBAC, admission, Pod Security Standards, NetworkPolicy, secrets, audit.
  • NSA/CISA Kubernetes Hardening Guidance.
  • OPA/Gatekeeper and Kyverno documentation; Falco (runtime detection).

Identity and attack paths

  • "Cloud IAM privilege escalation" research (e.g. Rhino Security Labs AWS escalation methods).
  • SPIFFE/SPIRE specification; GitHub Actions OIDC federation docs.
  • Prowler / ScoutSuite (assessment in owned accounts only).

Compliance

  • NIST SP 800-53 and SP 800-207 (Zero Trust Architecture); FedRAMP documentation.
  • PCI DSS v4.0; HIPAA Security Rule; AICPA SOC 2 Trust Services Criteria; ISO/IEC 27001/27002.

Infrastructure as code

  • Terraform/OpenTofu security docs; Checkov, tfsec, Conftest documentation.