Unit 4 — Secure Compute, Containers & Endpoint Baselines

Unit 4 — Secure Compute, Containers & Endpoint Baselines (VM/Bastion/JIT, AKS/ACI/ACA/ACR, IoT/OT)

Companion notes: Cheat-sheet · §3 Compute/Containers · High-ROI · Unit 4 · 99-Appendix

1. Remote access to VMs — Azure Bastion + JIT

Azure Bastion is a managed PaaS jump host that provides RDP/SSH to VMs over TLS 443 from the Azure portal (or native client) without exposing the VM to the internet.

Key configuration facts:

• Deploy Bastion into a dedicated subnet named exactly AzureBastionSubnet (the name is mandatory — Bastion will not deploy otherwise).
• Subnet size: for dedicated SKUs, the subnet must be /26 or larger. (Per current Microsoft guidance the /26 minimum applies to all dedicated-SKU Bastion deployments created on or after 2 Nov 2021, not only Standard/Premium — size for /26 and you are safe across SKUs.)
• Target VMs need no public IP and no inbound NSG rule for 3389/22 from the internet — Bastion reaches them on their private IP.
• SKU ladder:
  • Basic — portal-based RDP/SSH.
  • Standard — adds the native desktop client, IP-based (IP-Connect) connection to non-Azure / on-prem targets, host scaling, shareable links, and Kerberos. Remember native client and shareable links are Standard+ features.
  • Premium — adds session recording and private-only deployment.

Just-in-time (JIT) VM access is a Microsoft Defender for Cloud capability (requires Defender for Servers Plan 2):

• Defender programs deny rules in the NSG (and Azure Firewall, if present) so selected management ports are closed by default.
• A user with the right RBAC permission requests access; on approval, Defender inserts a time-boxed allow rule scoped to the requester’s source IP for a configured number of hours, then auto-reverts.
• JIT and Bastion compose — Bastion governs the connection path; JIT governs whether the port is open at all. You can JIT-protect even Bastion-fronted VMs.

AZ-500 (operate): configure the subnet/SKU, enable JIT, request access (knowing JIT needs Plan 2). SC-100 (design): specify “no public management endpoints, time-boxed elevation” as a Zero-Trust server requirement — the answer is private IPs + Bastion + JIT (+ PIM for the approval identity).

2. Disk encryption — four options, precise differences

This is the single highest-yield table in the unit. Know what each option encrypts, the key path, the CPU cost, and what Defender for Cloud reports — the Healthy/Unhealthy column is a recurring exam tell.

Critical exam points:

• SSE is always enabled and cannot be turned off. It encrypts OS/data disks at rest but not temp disks or caches, which is exactly why Defender for Cloud flags SSE-only VMs Unhealthy for disk encryption. “We have SSE” therefore does not satisfy a “encrypt everything including temp disk” requirement.
• Encryption at host is Microsoft’s recommended path for new VMs — no CPU cost (host-level), end-to-end coverage (temp disks, caches, and the compute↔storage data flow), works with custom images. Defender reports Healthy. (Nuance: temp-disk encryption under encryption at host is supported only with the platform-managed key.)
• ADE uses BitLocker (Windows) / dm-crypt (Linux) integrated with Azure Key Vault (KEK), runs in-guest (consumes VM CPU), and is scheduled to retire September 15, 2028 — after which ADE-encrypted disks fail to unlock on reboot. There is no in-place conversion; existing ADE VMs must be migrated (rebuild disks/VMs). Do not design new workloads on ADE.
• Confidential disk encryption is for confidential VM sizes (DCasv5 / ECasv5), ties keys to the VM’s vTPM, is currently OS-disk only, and is the control when the threat model must exclude the host/hypervisor operator from the trust boundary.
• CMK / BYOK for SSE, encryption-at-host, and confidential disk all route through a Disk Encryption Set (DES) referencing Key Vault Premium or Managed HSM.

AZ-500: enable the right option per requirement. SC-100: specify the baseline — “encryption at host with CMK via DES” for general IaaS; “confidential VM + confidential disk encryption” for untrusted-host threat models.

3. AKS — network isolation, authentication, authorization, monitoring

3.1 Network isolation (builds on the networking unit)

• Private cluster — the Kubernetes API server gets a private endpoint; no public API IP. Where a public endpoint is retained, restrict it with API server authorized IP ranges.
• Network policy (east-west pod traffic) — engines: Azure, Calico, or Cilium (Azure CNI Powered by Cilium). Network policy must be selected at cluster create for some engines.
• CNI — Azure CNI / Azure CNI Overlay for routable or overlay pod networking; integrate with a hub-spoke topology.
• Egress control — route node egress through Azure Firewall via a UDR, allowing only required FQDNs/tags (outbound lockdown).

3.2 Authentication (who are you to the API server)

• Microsoft Entra integration (recommended) — the cluster validates API requests against Entra ID, inheriting Conditional Access, MFA, and PIM plus centralized audit. The Entra tenant must match the subscription’s tenant. Use kubelogin for non-interactive / older kubectl.
• Local accounts — a built-in cluster-admin certificate that bypasses Entra entirely. Anyone who can list it gets cluster-admin with no Conditional Access and no audit trail. Disable in production (az aks update --disable-local-accounts) and enforce fleet-wide with the Azure Policy “Azure Kubernetes Service Clusters should have local authentication methods disabled.”
• External OIDC providers (preview) — only when identity must live outside Entra.
• Node SSH — three modes: disabled SSH (preview, production-preferred), Microsoft Entra ID based SSH (preview — no keys, inherits CA/MFA/PIM), and local-user SSH (key-based, rotate regularly).

3.3 Authorization (what can you do)

• Kubernetes RBAC — native Role / ClusterRole / RoleBinding, evaluated in-cluster.
• Microsoft Entra ID / Azure RBAC for Kubernetes — an authorization webhook delegates to Entra; Azure role assignments with dataActions govern standard K8s resources (ABAC conditions cover custom resources). One assignment at subscription / management-group scope can govern many clusters — the fleet-scale choice for central, audited governance.

3.4 Workload identity

• Microsoft Entra Workload ID uses OIDC federation + projected service-account tokens so pods authenticate to Azure resources without secrets. It replaces the deprecated pod-managed identity — do not design new clusters on pod-managed identity.

3.5 Secure & monitor

• Microsoft Defender for Containers — runtime threat detection (agentless discovery + Defender sensor/DaemonSet), Kubernetes data-plane hardening recommendations, and image vulnerability scanning via Microsoft Defender Vulnerability Management (MDVM). Scope: Kubernetes environments — AKS, plus EKS, GKE, and Azure Arc-enabled Kubernetes. (See the ACI/ACA scope correction in §4.)
• Azure Policy add-on for AKS (Gatekeeper / OPA) — enforce constraints as audit/deny (no privileged pods, allowed registries only, required labels).
• Azure Monitor / Container Insights + diagnostic settings → Log Analytics → Microsoft Sentinel.

AZ-500: every bullet under “configure network isolation / secure & monitor / configure authentication for AKS” is testable. SC-100: synthesize “container-orchestration security requirements” into a design — private API, Entra + Azure RBAC, no local accounts, Workload ID, Defender for Containers, Policy add-on, egress lockdown.

4. ACI & ACA — security monitoring

4.1 Azure Container Instances (ACI)

• Single-container / container-group serverless compute.
• Pull images using a managed identity assigned AcrPull on the registry — avoid admin creds. (The Azure-portal “deploy from registry” flow historically still requires the ACR admin account — a known wrinkle; see §5 and §6.)
• Security monitoring is via Azure Monitor / Log Analytics (container group logs/metrics). Threat-detection for the ACI runtime is not provided by Defender for Containers — design accordingly.
• Harden with VNet integration (private deployment); no public exposure unless required.

4.2 Azure Container Apps (ACA)

• Serverless containers on a managed Kubernetes (KEDA / Dapr / Envoy) foundation; you do not manage the cluster.
• Managed identity for registry pulls and downstream Azure access; Dapr for secure service-to-service; built-in authentication (“EasyAuth”) in front of ingress.
• Monitoring: the Container Apps environment streams to Log Analytics + Azure Monitor; control ingress (internal-only vs external) and apply IP restrictions.
• Like ACI, ACA runtime is not in Defender for Containers’ supported runtime scope; rely on Azure Monitor/Log Analytics for security telemetry and on ACR registry scanning for image vulnerabilities.

AZ-500: “configure security monitoring for ACI/ACA” = Azure Monitor / Log Analytics wiring + managed-identity pulls (and knowing the Defender-for-Containers scope boundary). SC-100: specify identity-based pulls, private ingress, and centralized logging as container requirements.

5. ACR — managing access

5.1 Admin account — disabled by default, keep it off

Every Azure Container Registry includes an admin account that is disabled by default. It is a single shared credential (username + password) intended for testing, where all callers appear as one identity with push+pull — so there is no per-user audit. Keep it off; enforce with Azure Policy:

• “Container registries should have local admin account disabled” — Audit / Deny effects.
• “Configure container registries to disable local admin account” — Modify effect.

5.2 Entra RBAC — two permission modes (the prime distractor zone)

Mode A — “RBAC Registry Permissions” (classic):

• AcrPull — data-plane pull/read.
• AcrPush — push and pull.
• AcrDelete — delete.
• AcrImageSigner — Docker Content Trust signing. Deprecated (DCT is slated for removal 2028-03-31); still honored today, but do not use for new work.
• AcrQuarantineReader / AcrQuarantineWriter — quarantine workflow.
• Control-plane management uses Container Registry Contributor and Data Access Configuration Administrator (creates/deletes the registry, can enable admin / anonymous pull) — it does not grant data-plane push/pull.

Mode B — “RBAC Registry + ABAC Repository Permissions”:

• AcrPull / AcrPush / AcrDelete are NOT honored in this mode.
• Use Container Registry Repository Reader / Writer / Contributor, optionally with ABAC conditions scoping to specific repositories (the per-repo least-privilege answer — e.g., a scanner that may read exactly one repo).
• Standard Owner / Contributor / Reader grant only control-plane rights here.
• Listing repositories requires the separate Container Registry Repository Catalog Lister role (no ABAC conditions).

5.3 Non-Entra access — tokens + scope maps

• Repository-scoped credentials with an expirable / disable-able password, bound to a scope map granting content/read, content/write, content/delete, metadata/read, metadata/write per repository.
• For systems that cannot use Entra.
• Tokens cannot list the full catalog.

5.4 Workload pulls & network hardening

• AKS kubelet identity, ACA, ACI, Azure ML pull via managed identity assigned AcrPull (or the ABAC repository-reader role) — no stored secrets.
• Network: Private Link / private endpoint, disable public network access, selected-network firewall rules, trusted-services bypass. (Network plumbing detail belongs to Secure Networking & Edge Protection.)

AZ-500: “manage access to ACR” = admin-off + correct role per scenario + managed-identity pulls. SC-100: the container-security design principle — least privilege, per-repo scoping, identity-based pulls, no shared admin.

6. SC-100 baselines & endpoint requirements

6.1 Security baselines (servers, clients, PaaS/SaaS/IaaS)

• The reference is the Microsoft cloud security benchmark (MCSB) plus per-service Azure security baselines. Assess compliance through the Defender for Cloud regulatory-compliance dashboard; enforce with Azure Policy initiatives.
• OS hardening baselines (CIS / Microsoft security baselines) are delivered via Microsoft Intune (client/endpoint), Microsoft Defender for Endpoint (security configuration), or Azure Machine Configuration / guest configuration for in-OS VM settings.
• Multi-platform / hybrid servers: onboard non-Azure and on-prem machines with Azure Arc, then apply Defender for Servers + MDVM + baselines uniformly. (Defender for Servers itself is the posture unit’s topic — see Posture, Governance, Multicloud & Compliance.)

6.2 Windows LAPS (explicit SC-100 objective)

Windows LAPS automatically manages, rotates, and backs up the built-in local administrator password, so every device has a unique credential — directly defeating pass-the-hash and lateral traversal.

• AD encrypted-password decrypt rights are controlled by the ADPasswordEncryptionPrincipal policy setting — which defaults to the device’s Domain Admins group when not configured (requires ADPasswordEncryptionEnabled = True, the default).
• Operations: force early rotation with Reset-LapsPassword. Entra ID does not support expiring the stored password via a timestamp (that is an AD-only mechanism); OS-image-rollback detection is also AD-only (Server 2025 schema).
• GA with Microsoft Entra ID + Intune support: October 23, 2023.

6.3 Mobile devices & clients

• Microsoft Intune for MDM/MAM, compliance policies, configuration/hardening profiles, and endpoint protection — paired with Microsoft Defender for Endpoint. (Intune as a full device-management solution is covered in the capstone / M365 unit, Apps/API, M365 Data Protection & Strategy; here it is the delivery vehicle for baselines.)

7. IoT / OT and embedded systems

Microsoft Defender for IoT is the designated solution for OT and ICS:

• Agentless, passive network monitoring via sensors on SPAN ports / TAPs — discovers OT/ICS assets, builds a device inventory, baselines protocols, and detects anomalies without touching fragile control devices.
• Integrates with Microsoft Sentinel for cross-domain correlation and SOC workflows.
• Design OT detection coverage against the MITRE ATT&CK for ICS matrix. (SC-100 explicitly tests ATT&CK Enterprise / Mobile / ICS for coverage design — see Security Operations: Sentinel, Defender XDR, SOAR.)
• Enterprise IoT devices integrate with Microsoft Defender for Endpoint for discovery and protection.
• Embedded / constrained devices and IoT workloads: specify secure provisioning/attestation, device hardening, least-privilege device identity, and secure update channels; treat the IoT Hub / data path with private networking and managed identity.

8. Azure AI services security (SC-100)

When evaluating Azure AI services security, specify:

• Identity over keys — Microsoft Entra authentication + managed identity; disable/avoid account keys.
• Network — private endpoints and disabled public access to keep inference traffic off the internet.
• Data protection — customer-managed keys (CMK), data residency / region controls, and content logging/retention configuration to prevent data exfiltration through prompts/responses.
• Abuse & safety — content filtering / abuse monitoring, responsible-AI guardrails.
• Authorization — RBAC scoped to the AI resource.

AZ-500 (operate) ↔ SC-100 (architect) — the throughline

For every surface in this unit, AZ-500 hands you the configuration verb and SC-100 hands you the design verb:

The fastest path through both exams is to learn the control once at the operate altitude, then state the requirement it satisfies at the design altitude.

Cross-references

• Prerequisites: Identity, Access & Privileged Access · Secure Networking & Edge Protection · Data, Storage & Key Management
• Consumes / observed by: Posture, Governance, Multicloud & Compliance (Defender for Servers, MDVM, EASM, Secure Score, regulatory-compliance dashboard) · Security Operations: Sentinel, Defender XDR, SOAR (Defender for IoT / Container alert correlation, MITRE ATT&CK)
• Endpoint management depth: Capstone: Apps/API, M365 Data Protection & Strategy (Microsoft Intune device management, Microsoft Purview)
• Quick reference: Cheat-sheet §3 · Worked scenarios: High-ROI Unit 4 · Glossary, coverage map & sources: 99-Appendix

Authoritative references

• Azure Bastion configuration settings
• Azure Bastion SKU comparison
• JIT VM access overview
• VM disk encryption overview
• Confidential VM overview
• AKS cluster authentication concepts
• AKS cluster authorization concepts
• AKS Entra ID control-plane authentication (break-glass)
• AKS workload identity overview
• Defender for Containers introduction
• Defender for Containers support matrix
• ACR authentication (admin account)
• ACR RBAC built-in roles overview
• ACR RBAC + ABAC repository permissions
• ACR token-based repository permissions
• ACR built-in policy reference
• Windows LAPS overview
• Windows LAPS concepts
• Windows LAPS management policy settings
• Defender for IoT organizations overview
• Microsoft cloud security benchmark — introduction
• AZ-500 study guide · SC-100 study guide