AZ-500 Objective 3.1: Plan and Implement Advanced Security for Compute

Understanding Advanced Compute Security

Cloud compute resources—virtual machines, containers, Kubernetes clusters, and APIs—form the foundation of cloud applications requiring comprehensive security controls. Compute security challenges include remote access management preventing unauthorized access to VMs through exposed RDP/SSH ports, container vulnerabilities from insecure images and misconfigurations, Kubernetes complexity with numerous configuration options affecting security posture, API security protecting backend services from attacks and abuse, and data protection ensuring sensitive data encrypted at rest and in transit. Traditional approaches often expose management ports to internet, use static credentials, lack granular access controls, and have limited visibility into security events. Azure provides advanced compute security capabilities addressing these challenges: Azure Bastion and JIT access eliminate public VM exposure while maintaining administrative access, Kubernetes security features enable network isolation and policy enforcement, Defender for Containers provides vulnerability scanning and threat detection, managed identities eliminate credential management, disk encryption protects data at rest, and API Management centralizes API security controls.

Comprehensive compute security requires defense-in-depth across multiple layers: Access control layer restricts who can connect to compute resources through identity, authentication, network controls. Network isolation layer segments workloads preventing lateral movement through VNet integration, network policies, firewall rules. Application security layer protects running applications with vulnerability scanning, runtime protection, secrets management. Data protection layer encrypts sensitive data at rest and in transit using disk encryption, TLS, customer-managed keys. Monitoring and response layer detects threats and anomalies through logging, security monitoring, automated response. This objective explores Azure's advanced compute security features enabling implementation of defense-in-depth protecting VMs, containers, Kubernetes, and APIs from evolving threats while maintaining operational efficiency and compliance with security standards and regulations.

Remote Access to Virtual Machines

Azure Bastion Architecture and Deployment

Azure Bastion is fully managed PaaS service providing secure RDP and SSH connectivity to VMs directly from Azure portal over SSL without requiring public IPs on VMs or exposing management ports to internet. Traditional VM access requires public IP addresses with NSG rules allowing RDP (3389) or SSH (22) from internet or specific IP ranges, creating persistent attack surface vulnerable to brute force attacks, credential stuffing, and exploitation of RDP/SSH vulnerabilities. Azure Bastion eliminates these risks by deploying in dedicated subnet (AzureBastionSubnet) acting as jump server between Azure portal and VMs. Users connect to Bastion through browser or Azure CLI using Azure AD authentication, Bastion then connects to target VM using private IP address, traffic encrypted end-to-end with TLS 1.2.

Bastion deployment: Create dedicated subnet named exactly "AzureBastionSubnet" (Azure validation requires exact name) sized /26 or larger (/26 provides 64 addresses supporting up to ~50 simultaneous sessions for Basic tier). Deploy Azure Bastion resource in VNet specifying AzureBastionSubnet and public IP (Standard SKU). Bastion deployment takes 5-10 minutes. Once deployed, select VM in portal → Connect → Bastion → Enter credentials → Connect in browser tab. Bastion SKUs: Basic tier (default) supports up to 50 concurrent sessions, RDP and SSH to VMs in same VNet or peered VNets, copy/paste between local and remote session. Standard tier (formerly Premium) provides higher scale (unlimited sessions, more scale units), IP-based connection (connect using IP address not VM resource), file transfer between local machine and VM (up to 4GB), native client support for better performance than browser, additional monitoring capabilities. Choose Basic for typical scenarios, Standard for larger deployments or when file transfer needed.

Azure Bastion Security Configuration

Network security for Bastion: Configure NSG on AzureBastionSubnet with specific rules required for Bastion functionality. Inbound rules: Allow port 443 from Internet service tag (user connections from browsers), GatewayManager service tag (Azure management of Bastion service), AzureLoadBalancer service tag (health probes). Outbound rules: Allow port 443 to VirtualNetwork service tag (Bastion connects to VMs), AzureCloud service tag (communicates with Azure services), Internet service tag (updates and monitoring). Configure NSGs on VM subnets allowing RDP (3389) and SSH (22) only from AzureBastionSubnet source, blocking direct access from internet. This creates layered security—Bastion provides controlled entry point, VMs only accept connections from Bastion. Benefits: No public IP addresses on VMs eliminating attack surface, session recording for compliance and audit, Azure portal integration with single sign-on and MFA, supports Conditional Access policies for additional security, connections encrypted with TLS protecting credentials and data, no Bastion agent or software required on VMs, simplified access management through Azure RBAC.

Bastion best practices: Deploy Bastion in hub VNet for hub-spoke architecture enabling spoke VMs to use shared Bastion (requires VNet peering), use Standard tier for production environments requiring high scale or file transfer, configure diagnostic logs sending Bastion audit events to Log Analytics (captures who connected to which VM when), implement Conditional Access requiring MFA for Bastion access, use RBAC controlling who can use Bastion (Virtual Machine Administrator Login or Virtual Machine User Login roles on VMs), document emergency access procedures if Bastion unavailable, test connectivity regularly ensuring functionality, monitor Bastion metrics (active sessions, connection attempts, data processed), implement cost monitoring as Bastion charged per hour, consider Bastion shared service model for multi-subscription organizations. Limitations: Bastion requires HTML5-compatible browser, copy/paste limitations for some browsers, file transfer only in Standard tier, IP-based connection requires Standard tier, cross-region connections not supported (Bastion and VM must be in same region or peered VNets).

Just-in-Time VM Access

Just-in-time (JIT) VM access in Microsoft Defender for Cloud provides time-limited access to VM management ports reducing persistent exposure. JIT closes management ports by default through NSG deny rules, users request access specifying time period, request evaluated against policy, approved requests temporarily modify NSG opening ports, access automatically expires after configured duration. JIT prerequisites: Enable Microsoft Defender for Servers (Plan 1 or Plan 2), VMs must have NSG associated (subnet or NIC level), Defender for Cloud must have permissions to modify NSG rules. Configuration: Security Center → Just-in-time VM access → Configure → Select VMs → Configure ports (default: 3389, 22, 5985, 5986), set maximum request time (default 3 hours, max 24 hours), specify allowed source IPs (Any, Requesting IP only, Per source IP, Custom range). Save JIT policy.

Requesting JIT access: User selects VM in Security Center or portal → Request access → Select port (3389 for RDP, 22 for SSH), time range (default 3 hours), source IP (My IP recommended), reason (optional but recommended for audit), submit request. Defender for Cloud evaluates request against policy, if approved modifies NSG adding allow rule for specified duration with high priority, user receives notification of approval, after time expires NSG rule automatically removed. JIT logs: All requests logged in Activity Log and Defender for Cloud security alerts, captures username, timestamp, source IP, approval/denial, port accessed. Query logs identifying access patterns, audit trail for compliance, detecting unauthorized access attempts. JIT benefits: Reduces window of exposure—ports open only when needed, audit trail tracking who accessed VMs with business justification, integrates with RBAC and Conditional Access controlling who can request JIT access, prevents persistent exposure even if credentials compromised, supports compliance requirements for time-limited privileged access. JIT limitations: Requires Defender for Servers (paid), doesn't prevent access through other methods (Azure Bastion, VPN), 24-hour maximum access window, only controls specified ports (doesn't affect other ports), NSG modifications may conflict with other automation. Best practices: Use JIT for temporary access needs (troubleshooting, maintenance), combine with Bastion for regular access (Bastion primary, JIT secondary), configure alerts on JIT requests for security monitoring, require business justification for audit trail, restrict allowed source IPs to known ranges, use shortest time window necessary, regularly review JIT access logs, document JIT request approval process, train users on proper JIT usage, disable JIT ports not needed (remove unused ports from policy).

AKS Network Isolation and Security

AKS Networking Models and Network Policies

AKS networking determines how pods and services communicate and connect to external resources. Kubenet (basic networking): Default mode where pods get IP addresses from private CIDR separate from VNet address space, node VMs get VNet IPs, Azure automatically manages routing between pods and VMs using route tables, pods communicate with external resources through NAT from node's IP. Simpler but limited—pods not directly routable from VNet without custom routing, doesn't support Windows containers or Virtual Nodes. Suitable for development, small clusters, or scenarios where pod IPs from VNet not required. Azure CNI (Container Network Interface): Advanced mode where every pod gets IP directly from VNet subnet, pods routable within VNet and peered VNets, required for Windows node pools, Virtual Nodes (serverless AKS), Private Clusters, and integration with Azure networking features (NSGs, Private Link, Service Endpoints). Requires careful subnet planning—calculate IPs: (max nodes × max pods per node) + nodes + services. Example: 10 nodes, 30 pods per node = 310 IPs, recommend /23 or larger subnet. Azure CNI benefits: Full VNet integration, pods accessible from on-premises via VPN/ExpressRoute, supports Windows workloads, enables Private Link to pods, NSG rules on pod traffic. Choose Azure CNI for production environments requiring network integration.

Network policies enforce microsegmentation controlling traffic between pods. Without policies, all pods can communicate freely—security risk allowing lateral movement if pod compromised. Network policies defined using YAML specifying ingress and egress rules with pod selectors, namespace selectors, port restrictions. Azure Network Policy: Native Azure implementation optimized for Azure CNI, uses Azure NPM (Network Policy Manager) running as DaemonSet on each node, integrated with Azure monitoring and logging, performs well at large scale (thousands of policies). Enable during cluster creation (--network-policy azure) or on existing cluster. Calico Network Policy: Third-party implementation with rich features, supports Kubenet and Azure CNI, provides advanced capabilities (global policies, DNS-based policies, host endpoint protection, egress gateway), larger ecosystem with Calico Enterprise for additional security and observability. Enable with --network-policy calico. Choose Azure for simplicity and Azure integration, Calico for advanced features and multi-cloud consistency.

Network policy examples: Deny all ingress—default deny policy for namespace ensuring only explicitly allowed traffic accepted. Allow specific pods—allow front-end pods to access back-end pods on port 8080 denying other sources. Namespace isolation—pods in namespace-A can't access namespace-B unless explicitly allowed. Egress restriction—pods can only access specific external IPs (database, API endpoints) blocking other outbound. DNS policy—allow DNS queries to specific servers preventing DNS tunneling. Example policy denying all ingress to pods with label app=database except from pods with label app=api:apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-ingress-policy
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 5432

AKS Cluster Security and Monitoring

Securing AKS requires multiple layers. Private cluster: API server receives private IP address only accessible from VNet, requires VPN or ExpressRoute for management from on-premises, eliminates internet exposure of control plane, critical for production sensitive workloads. Enable with --enable-private-cluster. Authorized IP ranges: Alternative to private cluster restricting API server access to specific public IP ranges (corporate network, VPN endpoints, jump boxes). Configure with --api-server-authorized-ip-ranges. Prevents unauthorized network access even with credentials. Microsoft Defender for Containers: Comprehensive security for AKS providing vulnerability assessment (scans container images in ACR and running containers, identifies CVEs with severity scores, provides remediation guidance), threat detection (monitors control plane and nodes for suspicious activities like privilege escalations, malware, crypto-mining attempts, generates real-time alerts), security recommendations (compares cluster configuration against CIS Kubernetes Benchmark, identifies misconfigurations, provides step-by-step remediation), runtime protection (monitors workload behavior, blocks malicious processes, provides drift detection). Enable in Security Center selecting Defender for Containers plan applying to subscription.

Azure Policy for AKS: Enforces governance through policy engine running as admission controller. Built-in initiatives: Kubernetes cluster pod security baseline (prevents privileged containers, host networking usage, dangerous capabilities), pod security restricted (stricter controls following hardening best practices), custom policies for organization requirements. Policies audit non-compliant resources or deny/mutate resources violating policies. Examples: Require CPU/memory limits on containers, disallow privileged containers, enforce read-only root filesystems, restrict container images to approved registries, require labels for cost tracking. Pod Security Standards: Kubernetes-native security control at namespace level. Three profiles: Privileged (unrestricted access, no restrictions), Baseline (prevents known privilege escalations, drops dangerous capabilities, restricts host access), Restricted (heavily restricted following security hardening, drops all capabilities except NET_BIND_SERVICE, disallows privilege escalation, enforces read-only root filesystem, runs as non-root). Implement using pod security admission or Azure Policy. Set restricted profile for production namespaces.

Container Insights: Monitoring solution collecting metrics and logs from AKS clusters. Enable through portal, CLI, or ARM template specifying Log Analytics workspace. Collects: Container logs (stdout/stderr from containers), performance metrics (CPU, memory per pod and container), node metrics, Kubernetes events, inventory (pods, services, deployments). Provides: Live data view showing real-time pod logs and events, performance dashboards visualizing resource usage, alerts on threshold breaches (CPU exceeding 80%, pod restarts, node failures), workbooks for detailed analysis. Configure alerts: CPU/memory utilization, pod failures, container restarts, node NotReady state, control plane errors. Integrate with Azure Monitor Action Groups for notifications (email, SMS, webhook, Azure Function). Kubernetes audit logs: Capture all API server requests recording who performed what action when, essential for security investigations and compliance. Enable through diagnostic settings sending logs to Log Analytics, Storage, or Event Hubs. Query audit logs: Unusual pod creations, secret access patterns, privilege escalations, unapproved API calls, policy violations. Integrate with Azure Sentinel correlating AKS events with broader security context.

AKS Authentication and Authorization

AKS authentication: Azure AD integration provides centralized identity management for cluster access. Enable Azure AD managed integration (recommended over legacy mode) during cluster creation or update existing cluster. Users authenticate with Azure AD credentials supporting MFA and Conditional Access, no local Kubernetes user accounts, leverages Azure AD groups for role management. Configure: az aks create --enable-aad --aad-admin-group-object-ids [group-id] specifying Azure AD group containing cluster administrators. Kubernetes RBAC: After Azure AD authentication, determines what users can do in cluster. ClusterRole defines cluster-wide permissions, Role defines namespace permissions. ClusterRoleBinding and RoleBinding associate roles with Azure AD users/groups. Built-in roles: cluster-admin (full cluster access), admin (full namespace access), edit (read/write namespace resources except RBAC), view (read-only). Best practice: Create Azure AD groups for different roles (cluster-admins, app-developers, monitoring-team), bind groups to appropriate Kubernetes roles, manage access through Azure AD group membership not individual bindings.

Azure RBAC for AKS: Alternative authorization using Azure-native RBAC instead of Kubernetes RBAC. Benefits: Unified permission model (same RBAC across Azure resources and AKS), Azure portal management (familiar interface for admins), Azure AD integration (groups, Conditional Access, PIM), auditing through Azure Activity Log. Built-in roles: Azure Kubernetes Service Cluster Admin Role (full admin including kubeconfig download), Cluster User Role (kubeconfig download with limited permissions), RBAC Admin (admin via Azure RBAC), RBAC Cluster Admin (cluster-admin via Azure RBAC), RBAC Reader (read-only via Azure RBAC), RBAC Writer (read-write via Azure RBAC). Enable: --enable-azure-rbac during creation or update. Assign roles: Azure portal → AKS cluster → Access Control (IAM) → Add role assignment → Select role and Azure AD identity. Local accounts: Kubernetes creates default certificate-based authentication—insecure as tokens don't expire. Disable local accounts (--disable-local-accounts) forcing all access through Azure AD. Prevents persistent access if credentials compromised. Kubectl access: Users run az aks get-credentials retrieving kubeconfig with Azure AD authentication provider. First kubectl command triggers browser authentication flow logging into Azure AD. Token cached locally, refreshed automatically when expired. Conditional Access and MFA enforced during authentication providing strong security. Best practices: Enable Azure AD managed integration, disable local accounts, use Azure RBAC for simplified management or Kubernetes RBAC for granular control, create Azure AD groups for role management, configure authorized IP ranges restricting API server access, use private cluster for maximum security, implement JIT access using PIM for administrative roles, enable audit logging capturing authentication events, regularly review role assignments removing unnecessary access, document authentication and authorization architecture for compliance.

Container Security Monitoring

Azure Container Instances Security

ACI provides serverless container execution without managing infrastructure. Security monitoring: Microsoft Defender for Containers scans ACI container images (if from ACR) detecting vulnerabilities before and during runtime. Enable diagnostic settings on container groups collecting logs: ContainerInstanceLog (application stdout/stderr), ContainerEvent (lifecycle events like start, stop, killed). Send to Log Analytics for querying and alerting. Monitor: Application logs for errors and anomalies, resource metrics (CPU, memory, network), container lifecycle events (unexpected restarts indicating issues), failed authentication attempts to services. Configure alerts: Container failures or restarts, resource exhaustion (CPU or memory limits reached), application errors in logs, unusual network traffic patterns. Network security: Deploy container groups in VNet for network isolation, configure NSGs on subnet controlling inbound/outbound traffic, use Private Endpoints for accessing Azure services from containers, avoid public IP addresses when possible (use private IPs with Load Balancer or Application Gateway for ingress). VNet integration enables: Private connectivity to Azure services, on-premises access via VPN/ExpressRoute, NSG-based filtering, integration with Azure Firewall. Secrets management: Pass secrets as environment variables (encrypted at rest), mount secrets from files (volume mount), integrate with Key Vault storing secrets securely (retrieve via init containers or sidecar), avoid embedding secrets in container images, rotate secrets regularly.

Managed identity for ACI: Enable system-assigned managed identity on container group providing identity for accessing Azure resources without credentials. Use managed identity for: Key Vault access retrieving secrets at runtime, Azure Storage access reading/writing data, SQL Database authentication, any Azure service supporting managed identity. Image security: Pull images from trusted registries (ACR), scan images with Defender before deployment, use content trust (Docker Content Trust) for image signing, regularly update base images patching vulnerabilities. Security context: Run containers as non-root user when possible, implement read-only root filesystem preventing file modifications, drop unnecessary Linux capabilities limiting attack surface. Best practices: Deploy in VNet with NSG rules, enable diagnostic logging to Log Analytics, use managed identities for Azure access, implement least privilege for container security contexts, regularly update container images, configure health probes for reliability, monitor logs for security events and anomalies, restrict network egress to required destinations only, document container image sources and versions, conduct security scanning in CI/CD pipeline before deployment.

Azure Container Apps Security

Container Apps provide managed Kubernetes-based platform with serverless consumption model. Security advantages: Built-in features (ingress, scaling, secrets management), VNet integration for network isolation, managed identity support, built-in authentication. Container Apps environment: Shared boundary for container apps deployed in VNet subnet (minimum /21 for large deployments). All apps in environment share network and logging configuration. Security monitoring: Enable Azure Monitor collecting logs and metrics: Console logs (stdout/stderr), system logs (app lifecycle events, scaling), request logs (HTTP traffic if enabled). Configure Log Analytics workspace for centralized logging. Monitor: Application performance and errors, scaling events and resource usage, authentication failures, HTTP error rates and status codes, security events and anomalies. Configure alerts: High error rates indicating issues, unusual traffic patterns, authentication failures suggesting attacks, resource exhaustion, scaling failures. Diagnostics logs provide: Timestamp, log level, message, source container, trace IDs for correlation. Query using Kusto in Log Analytics workbooks.

Network security: Container Apps deployed in VNet-integrated environment with dedicated subnet. Configure NSG on subnet restricting traffic. Ingress configuration: External (accessible from internet), Internal (accessible only within VNet), Disabled (no ingress). Use internal ingress for backend services accessed only by other apps in VNet. Ingress settings: Enable HTTPS (recommended), configure custom domains with SSL certificates, implement IP restrictions limiting source IPs, configure CORS for API security. Authentication: Built-in authentication (Easy Auth) provides authentication without code changes, supports Azure AD (primary for enterprise apps), OAuth providers (GitHub, Google, Facebook, Microsoft), JWT validation for APIs, logout support. Configure in portal or YAML defining identity providers, redirect rules, token store settings. Benefits: No authentication code in application, centralized configuration, token refresh handling, integration with Conditional Access and MFA. Secrets management: Define secrets in Container App configuration (encrypted at rest and in transit), reference secrets in environment variables or volume mounts, integrate with Key Vault for secret storage (KeyVault reference in secret definition), rotate secrets without redeploying apps. Managed identity: Enable system-assigned or user-assigned managed identity, use for Key Vault access, Azure services (Storage, SQL, Service Bus), Microsoft Graph API calls. Eliminates credential storage in code or configuration. Best practices: Deploy in VNet with internal ingress for non-public apps, enable built-in authentication for user-facing applications, use managed identities for Azure service access, store secrets in Key Vault not environment variables directly, configure NSGs on Container Apps subnet, enable diagnostic logging for monitoring and audit, implement resource limits preventing resource exhaustion attacks, use HTTPS for all external ingress, regularly update container images, configure health probes for reliability, monitor for security anomalies, integrate with Azure Sentinel for SIEM, implement egress filtering through firewall, conduct regular security assessments and penetration testing.

Azure Container Registry Access Management

ACR Authentication and Authorization

Azure Container Registry access control determines who can push and pull container images. Authentication methods: Azure AD authentication (recommended) using docker login with Azure AD tokens, suitable for users and service principals, supports MFA and Conditional Access. Managed identity (best for Azure resources) enables AKS, ACI, ACA accessing ACR without credentials, eliminates secret management, uses system-assigned or user-assigned identity. Admin user (not recommended) provides username/password, disabled by default, only enable for development or legacy integration, don't use in production. Service principal for automation creates dedicated identity for CI/CD pipelines with specific permissions, rotate credentials regularly. RBAC roles controlling ACR access: AcrPull (pull images only, suitable for production consumers), AcrPush (pull and push images, for developers and CI/CD), AcrDelete (delete images, for cleanup automation), AcrImageSigner (sign images for content trust, for security teams), Owner/Contributor (full management including RBAC assignment), Reader (view registry metadata, can't pull images). Assign roles: Portal → ACR → Access Control (IAM) → Add role assignment → Select role, identity (user, group, managed identity, service principal), scope (registry-wide or repository-specific).

Repository-scoped permissions: Granular access control at repository level within registry enables: Different teams managing different repositories (Team A pushes to app1/, Team B to app2/), shared base images (everyone pulls from base/), separation of environments (prod/ writable by CI/CD only). Configure through: Portal (ACR → Repository permissions), CLI (az acr repository commands), ARM templates. Example: Grant Team-A-SP AcrPush on myregistry.azurecr.io/app1/* and AcrPull on myregistry.azurecr.io/base/*. Tokens: Alternative authentication for automation and external access providing scoped, time-limited credentials. Generate token: Portal → ACR → Tokens → Add → Specify name, scope map (repositories and actions), expiration (optional). Token advantages: Scoped to specific repositories and actions (can't access other repositories), time-limited with expiration dates forcing rotation, revocable without affecting other access methods, auditable usage tracking token activity. Use cases: CI/CD pipelines, external partners pulling specific images, short-term project access, token per environment. Best practices: Use Azure AD authentication for users, managed identities for Azure resources accessing ACR, service principals with minimal permissions for CI/CD, never use admin user in production, implement repository-scoped permissions for multi-team scenarios, rotate service principal credentials regularly (90 days), use tokens for temporary or external access, monitor authentication events in logs, configure alerts on failed authentications, regularly audit ACR access removing unused accounts, document access patterns for compliance.

ACR Network Security and Image Protection

Network access controls: Public network access disabled blocks all internet access to registry. Configure allowed IP ranges for specific scenarios (corporate network, CI/CD agent IPs, on-premises datacenter). Service Endpoints optimize routing from VNet to ACR over Azure backbone, reduce latency, enable VNet firewall rules on ACR (ACR → Networking → Firewalls and virtual networks → Selected networks → Add VNet). Private Endpoints provide complete network isolation, ACR receives private IP in VNet, accessible from on-premises via VPN/ExpressRoute, DNS resolution via Private DNS Zone (privatelink.azurecr.io), eliminates public endpoint requirement. Enable in Premium SKU: Create Private Endpoint → Select ACR as resource → Configure VNet/subnet, DNS integration. Content trust: Ensures image integrity preventing tampering. Docker Content Trust (DCT) cryptographically signs images, only signed images pushable/pullable, notary server manages trust metadata. Enable: export DOCKER_CONTENT_TRUST=1. Sign images: docker push automatically prompts for signing key. Trust policies define which signed images acceptable. Azure Container Registry implements content trust using Notary v1. Benefits: Prevents unsigned image deployment, validates image publisher, ensures image hasn't been modified, meets compliance requirements for supply chain security.

Vulnerability scanning: Microsoft Defender for Containers automatically scans images pushed to ACR, identifies vulnerabilities (CVEs) with severity scores, provides remediation guidance (update base image, patch package, apply security fix), scan results visible in Security Center and portal. Configure: Security Center → Enable Defender for Containers, automatically scans all images in ACR. View results: ACR → Repository → Image → Security findings. Security recommendations: Update vulnerable packages, use minimal base images (alpine vs ubuntu full), regularly rebuild images picking up patches, implement scanning in CI/CD pipeline blocking vulnerable images. Quarantine pattern: Lock images until security validation complete, prevent deployment of unvalidated images, implement using ACR webhooks and automation: Image pushed → Quarantine enabled automatically → Security scan runs → Manual or automated review → If approved, quarantine removed → Image available for deployment. Image retention: Automatically delete old images reducing storage costs and attack surface, configure retention policies (days to retain, tag patterns, manifests to keep), implement lifecycle management: Tags older than X days deleted, Keep only last N versions, Preserve images with specific tags (prod, stable). Best practices: Disable public access or restrict to specific IPs, use Private Endpoints for production registries, enable content trust ensuring image integrity, enable Defender scanning all images, implement image quarantine for validation, configure retention policies cleaning old images, use geo-replication for multi-region availability, enable diagnostic logging for audit, regularly review access and permissions, integrate scanning in CI/CD pipelines, document approved base images, conduct regular security reviews of images, implement image promotion workflow (dev → test → prod registries).

Disk Encryption

Azure Disk Encryption (ADE)

Azure Disk Encryption provides full disk encryption using BitLocker (Windows) or dm-crypt (Linux) encrypting OS and data disks. Integrates with Azure Key Vault for key management: Encryption keys (Disk Encryption Key - DEK) stored in Key Vault, optional Key Encryption Key (KEK) encrypts DEK providing additional security layer, VM retrieves keys from Key Vault during boot. Prerequisites: VM in supported region and size (not Basic tier), Key Vault in same region and subscription, VM must have network access to Key Vault, Key Vault access policies allowing Azure Disk Encryption, sufficient disk space for encryption. Enable ADE: Portal (VM → Disks → Additional settings → Disks to encrypt → OS and data disks → Select Key Vault and KEK), CLI (az vm encryption enable --resource-group [RG] --name [VM] --disk-encryption-keyvault [KeyVault] --key-encryption-key [KEK]), PowerShell (Set-AzVMDiskEncryptionExtension). Encryption process: Extension deployed to VM, VM communicates with Key Vault retrieving encryption key, disk encrypted using BitLocker/dm-crypt with key, encrypted data written to Azure Storage, boot process retrieves key from Key Vault for decryption. Performance impact minimal after initial encryption.

Key management: DEK encrypts actual disk data, KEK protects DEK (optional but recommended), store KEK in Key Vault with appropriate access policies, Key Vault configured with: Soft delete (deleted keys recoverable for 90 days), Purge protection (prevents permanent deletion during retention period), Enable for Disk Encryption access policy. Benefits: Full disk encryption for compliance, integration with existing Key Vault key management, customer control over encryption keys, supports Windows and Linux, encrypted data at rest in Azure Storage. Limitations: Not supported on Basic tier VMs, certain VM sizes unsupported, requires managed disks, some Linux distributions have compatibility issues, initial encryption takes time (depends on disk size), requires VM access to Key Vault during boot. ADE vs server-side encryption: Azure Storage automatically encrypts all data at rest using platform-managed or customer-managed keys (server-side encryption always enabled), ADE provides additional full disk encryption inside VM (BitLocker/dm-crypt), server-side protects data in Azure Storage, ADE protects VM disk from unauthorized mounting, combine both for defense-in-depth. Use cases: Compliance requiring BitLocker or dm-crypt specifically, need encryption keys in your Key Vault, existing VMs requiring encryption, integration with on-premises encryption policies.

Encryption at Host and Confidential Disk Encryption

Encryption at host: Platform-level encryption at VM host (hypervisor layer) encrypting temp disk, OS and data disk caches, and managed disk data at rest. Advantages: Transparent encryption without VM agent or extension, encrypts temp disk and disk caches (ADE doesn't encrypt these), simpler than ADE (no Key Vault communication required), supports more VM sizes, better performance (hardware-based encryption), encrypts data before writing to Azure Storage. Enable: Requires one-time subscription registration (az feature register --namespace Microsoft.Compute --name EncryptionAtHost), select VM size supporting encryption at host (check documentation), enable during VM creation (--encryption-at-host) or on stopped VM. Can't enable on running VM. Encrypted components: Temp disk (ephemeral storage on host), OS disk cache (cache on host for performance), data disk cache, managed disk data (before writing to Storage). Benefits: Comprehensive encryption including temp disk, no extension needed, hardware-based for performance, supports Confidential Computing VMs, simpler operationally than ADE. Limitations: Not all VM sizes support (DCsv2, DCasv5, DCadsv5, ECasv5, ECadsv5, FXmdvs, and many others), requires subscription registration, can't enable on running VMs (must stop first), slightly higher cost than VMs without encryption at host.

Confidential disk encryption: Protects VMs using AMD SEV-SNP (Secure Nested Paging) confidential computing, encrypts disk with key bound to VM's Trusted Platform Module (TPM), encryption key never accessible to Azure platform or hypervisor, provides protection from Azure operators and physical attacks, highest security for regulated data. Requirements: Confidential Computing VM series (DCas_v5, DCads_v5, ECas_v5, ECads_v5), supported regions (limited availability), enable during confidential VM creation. Architecture: VM boot with secure boot and vTPM enabled, disk encryption key generated inside VM's secure enclave, key sealed to vTPM (hardware security), Azure platform cannot access key, decryption happens only inside secure enclave. Benefits: Protection from cloud provider (Azure operators can't access data), protection from physical attacks (data remains encrypted even if disks removed), strongest encryption for sensitive workloads, integrates with attestation proving VM integrity. Use cases: Financial data processing in cloud, healthcare PHI requiring maximum protection, government classified workloads, intellectual property processing, compliance requiring encryption beyond cloud provider's control. Comparison summary: ADE—full disk encryption with BitLocker/dm-crypt, requires Key Vault, most flexible. Encryption at host—hardware-based at hypervisor, includes temp disk and caches, simplest. Confidential disk encryption—hardware enclave protection, strongest isolation, limited VM sizes. All protect data at rest (Azure Storage server-side encryption always present). Best practices: Use encryption at host for new VMs where supported, implement ADE for existing VMs or specific BitLocker requirements, use confidential disk encryption for highest security workloads, store encryption keys in Key Vault with RBAC and audit, enable soft delete and purge protection on Key Vault, rotate keys periodically, monitor encryption status ensuring all VMs encrypted, test disaster recovery with encryption enabled, backup Key Vault encryption keys for recovery, document encryption approach for compliance audits.

API Management Security

API Management Authentication and Authorization

API Management security requires protecting APIs, backends, and management infrastructure. Authentication methods: Subscription keys (simplest) require API consumers include key in header (Ocp-Apim-Subscription-Key) or query string (subscription-key), subscriptions scoped to all APIs, single API, or product, regenerate keys for rotation, suitable for internal APIs with trusted clients. OAuth 2.0 authorization (recommended for external APIs) uses industry-standard OAuth 2.0 and OpenID Connect, API Management validates access tokens from Azure AD or third-party identity providers, enables fine-grained scopes and claims-based authorization, integrate with Azure AD Conditional Access and MFA. Configure: API → Settings → OAuth 2.0 authorization → Add authorization server → Configure token endpoint, client ID, client secret. JWT validation policy validates JSON Web Tokens in requests: <validate-jwt header-name="Authorization" failed-validation-httpcode="401"><openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" /><required-claims><claim name="aud"><value>{client-id}</value></claim></required-claims></validate-jwt>. Validates token signature, issuer, audience, expiration, custom claims.

Client certificates (mutual TLS) provide strongest authentication for B2B scenarios, requires clients present certificate during TLS handshake, API Management validates certificate thumbprint, issuer, subject, upload CA certificates for validation. Configure: API → Settings → Client certificate → Require certificate → Upload CA certificate. Backend authentication: API Management authenticates to backends using certificates, OAuth, or basic authentication eliminating need for backends to handle subscription keys, certificates more secure than basic auth. Network security: VNet integration deploys API Management into VNet (external or internal mode), external mode—API Gateway public, management private, internal mode—all endpoints private requiring Application Gateway or firewall for public access. Benefits: API Management accesses VNet resources (VMs, databases, Function Apps), NSG rules control traffic, Private Endpoints for backend services, network isolation from internet. Configure: API Management → Virtual network → Internal or External → Select VNet and subnet. Network restrictions: IP filtering allows specific IP ranges accessing APIs (<ip-filter action="allow"><address>1.2.3.4</address></ip-filter>), geo-filtering restricts by country/region, CORS policies control cross-origin requests from browsers. Best practices: Use OAuth 2.0 for external APIs with user authentication, implement JWT validation for API security, use client certificates for B2B integrations, deploy in VNet (internal mode) for production sensitive APIs, configure network restrictions (IP filtering, geo-filtering), disable basic authentication for backends using certificates instead, implement rate limiting and quotas, use managed identity for backend authentication, enable diagnostic logging for monitoring, integrate with Azure AD for developer portal access, regularly review and rotate credentials, conduct API security testing (OWASP API Security Top 10), document authentication architecture for compliance.

API Management Policies and Monitoring

API policies control request and response processing. Inbound policies (before forwarding to backend): validate-jwt—authentication, check-header—require specific headers, ip-filter—IP restrictions, rate-limit—throttling, quota—usage limits, cors—browser access control. Backend policies: modify request before backend, add authentication headers, circuit breaker for resilience, retry logic for failures. Outbound policies (before returning to client): transform response format, remove internal headers, set security headers (HSTS, X-Frame-Options, CSP), caching for performance. Error policies: custom error responses hiding internal details, logging errors for investigation, retry or failover logic. Policy examples: Rate limiting per subscription—<rate-limit calls="100" renewal-period="60" /> limits to 100 calls per minute. Quota per day—<quota calls="10000" renewal-period="86400" /> limits daily calls. IP filter—<ip-filter action="forbid"><address-range from="1.2.3.0" to="1.2.3.255" /></ip-filter> blocks IP range. Mock responses for development—<mock-response status-code="200" /> returns mocked data without backend call.

Monitoring and logging: Enable Application Insights collecting detailed telemetry (requests, failures, performance, dependencies, custom events), provides real-time monitoring dashboards, tracks API usage patterns, identifies slow operations. Configure diagnostic settings sending logs to Log Analytics, Storage, or Event Hub: Gateway logs (all API requests/responses), management operations (admin actions), metrics (requests, latency, capacity). Query logs: Failed authentications (potential attacks), Unusual traffic patterns, Backend errors, Performance issues, Policy violations. Create alerts: High error rates (4xx, 5xx), Latency exceeding threshold, Rate limit hits increasing, Backend failures, Unusual spike in requests. Integrate with Azure Sentinel for SIEM correlation. Developer portal security: Enable Azure AD authentication for portal, require approval for subscription requests, disable anonymous access to APIs, restrict portal visibility to internal network, configure custom domain with SSL, implement role-based access (admins, developers, read-only). Best practices: Implement comprehensive policy set (authentication, rate limiting, validation), use inbound policies for security checks, configure caching for performance, enable Application Insights for monitoring, configure alerts on critical metrics, secure developer portal with Azure AD, regularly review API usage identifying anomalies, conduct API security assessments (OWASP API Security), document policies and configurations, keep API Management updated with patches, implement disaster recovery with geo-replication, use Key Vault for secrets management.

Exam Preparation Tips

Key Concepts to Master

• Azure Bastion: Deployed in AzureBastionSubnet (/26 min), RDP/SSH over SSL without VM public IPs, Standard tier for file transfer and scale
• JIT VM access: Time-limited port opening (max 24 hours), requires Defender for Servers, modifies NSG automatically
• AKS networking: Kubenet (simple, pod IPs from overlay) vs Azure CNI (pod IPs from VNet, required for Windows)
• Network policies: Azure (optimized for CNI) vs Calico (advanced features), control pod-to-pod traffic
• AKS security: Defender for Containers (vulnerability scanning, threat detection), Azure Policy (pod security baseline/restricted), audit logs
• AKS authentication: Azure AD managed integration, Kubernetes RBAC vs Azure RBAC, disable local accounts
• Container monitoring: ACI—diagnostic logs to Log Analytics; ACA—built-in monitoring, built-in auth (Easy Auth)
• ACR access: RBAC roles (AcrPull, AcrPush), repository-scoped permissions, content trust, vulnerability scanning
• Disk encryption: ADE (BitLocker/dm-crypt with Key Vault), encryption at host (hardware-based, includes temp disk), confidential (AMD SEV-SNP)
• API Management: OAuth 2.0/JWT validation, VNet integration (external/internal), policies (rate limiting, JWT validation), Application Insights

Practice Questions

Hands-On Practice Lab

Lab Activities

Lab Outcomes

After completing this lab, you'll have hands-on experience with advanced compute security. You'll understand how Azure Bastion provides secure VM access without public IPs, JIT access offers time-limited port opening with automatic expiration, AKS network policies implement microsegmentation, and ACR integrates with Defender for vulnerability scanning. These practical skills demonstrate compute security capabilities tested in AZ-500 exam and provide foundation for implementing comprehensive compute protection in production Azure environments.

Frequently Asked Questions