Lab 06 — Azure Landing Zone, Entra Identity, and AKS Defense

Difficulty: 5/5 | Provider: Azure

Pairs with the whole Phase 07 WARMUP. Build the evaluator first; validate only in a disposable tenant/subscription. Same attack-path reasoning as AWS (04) and GCP (05), in Azure's model.

Why This Lab Exists (Purpose & Goal)

This is the third instance of the landing-zone exercise, in Azure's distinctive model — Entra ID (formerly Azure AD) identity, management groups, Azure RBAC, Privileged Identity Management, and AKS. The goal is the same secure foundation, and the deeper goal is fluency across all three major clouds: the principles are universal, but Azure's identity and governance mechanisms are specific enough that you must reason in them directly.

The Concept, In the Weeds

The attack story: a compromised CI federation subject traced through Entra workload identity, Azure RBAC, Key Vault, Storage, and AKS. The Azure-specific controls and pitfalls:

  • Permanent Subscription Owner is the over-privilege trap; Azure's answer is PIM (Privileged Identity Management) — eligible, time-bound, approved activation instead of standing privilege.
  • Broad federated subjects — exact federated credentials must pin the precise external subject (repo/branch), or any CI can impersonate (the WIF lesson, Azure edition).
  • Public Key Vault / Storage, missing purge protection — data exposure and irreversible-deletion risks; private endpoints + DNS and purge protection close them.
  • Public AKS administration, pod-held credentials — keep AKS private and give pods workload identity instead of node credentials (the K8s-to-cloud pivot, Azure edition).
  • Incomplete diagnostic settings — gaps in the audit trail; protected Log Analytics workspaces keep evidence beyond the attacker's reach.
  • Conditional Access is the policy engine for human sign-in — powerful, but with a critical operational hazard (below).

The governance hierarchy is management groups + Azure Policy as guardrails, with Conditional Access + PIM for identity. The defenses compose into the same defense-in-depth as the other clouds.

Why This Matters for Protecting the Company

Azure is the enterprise cloud for a huge share of organizations, and Entra ID is frequently the identity backbone for everything (including Microsoft 365). A landing-zone flaw here — a standing Owner, a loose federated credential, an unprotected Key Vault — has outsized blast radius because Azure identity reaches so far. There is also a uniquely Azure operational danger: a Conditional Access misconfiguration can lock every administrator out of the tenant. Building the Azure landing zone correctly — and establishing tested emergency access (break-glass) before enforcing Conditional Access — is how you protect the estate without causing a self-inflicted outage that is itself a severe incident.

Build It

LAB_MODULE=solution pytest -q

Then validate in a disposable tenant/subscription. Seed: permanent Subscription Owner, broad federated subjects, public Key Vault/Storage, missing purge protection, public AKS administration, pod-held credentials, incomplete diagnostic settings. Fix with: management groups + Azure Policy; PIM + Conditional Access; exact federated credentials; managed/workload identities; private endpoints + DNS; Key Vault role separation; private AKS; Defender/Monitor detections; protected log workspaces; and tested emergency access.

Deliver: policy assignments, exemption review, Entra/RBAC graph, activity and sign-in event IDs, synthetic detections, credential-revocation proof, restore evidence, teardown, cost report, and an executive memo. Do not lock out the tenant: establish and test emergency access before enforcing Conditional Access.

Validation — What You Should Be Able to Do Now

  • Reason about Azure authority via management groups, Azure RBAC, and PIM (eligible/time-bound activation instead of standing Owner).
  • Pin federated credentials to an exact external subject; separate Key Vault roles; keep AKS private.
  • Establish and test break-glass before enforcing Conditional Access, and explain why this ordering prevents a self-inflicted lockout.

The Broader Perspective

Completing the landing zone in all three clouds cements the multi-cloud security engineer's core competency: carry the universal principles, learn each provider's mechanisms and sharp edges, and respect each one's unique operational hazards. Azure adds a vital staff-level lesson the others underscore less: a security control can itself cause an outage (Conditional Access lockout), so hardening must be sequenced with safety (break-glass first) — the same judgment as OT's "isolation can be unsafe" (Phase 10) and IR's "containment can break availability" (Phase 09). Security that ignores its own operational blast radius is not mature security.

Interview Angle

  • "How do you avoid over-privilege and lockout in Azure?" — Replace standing Subscription Owner with PIM eligible/time-bound activation; pin federated credentials to exact subjects; and always establish and test break-glass emergency access before enforcing Conditional Access, so a policy mistake can't lock out every admin.

References

  • Phase 07 WARMUP; Microsoft Cloud Adoption Framework security; Entra ID, PIM, Conditional Access, Azure Policy, AKS documentation.