Unit 3: Secure Compute and Storage

I. Security Foundations for Azure Compute and Storage

Secure compute and storage in Microsoft Azure follow a shared-responsibility model: Microsoft secures the physical infrastructure and managed platform, while customers secure identities, configurations, workloads, data, and access. Effective protection combines zero-trust principles, least privilege, network segmentation, encryption, continuous monitoring, and controlled administrative access.

• Core characteristics:
  • Verify explicitly: Authenticate and authorize requests using identity, device, location, workload, and risk signals.
  • Least privilege: Grant only the permissions required, preferably for a limited period and scope.
  • Assume breach: Segment resources, monitor activity, and limit lateral movement.
  • Defense in depth: Combine identity, network, compute, application, and data controls.
  • Shared responsibility: Azure protects datacenters and foundational services; customers remain responsible for workload-specific security.
  • Encryption: Protect data in transit with TLS and data at rest with platform-managed or customer-managed keys.
  • Governance: Use Azure Policy, role-based access control, resource locks, and standardized deployment templates to maintain secure configurations.

II. Azure Bastion — Managed Administrative Connectivity

A. Azure Bastion

Azure Bastion is a platform-managed service that provides browser-based or native-client RDP and SSH access to Azure virtual machines without exposing those machines through public IP addresses.

• Architecture: Bastion is deployed into an Azure virtual network and connects to target VMs over their private IP addresses.
  • The dedicated subnet is conventionally named AzureBastionSubnet.
  • The subnet size must satisfy the requirements of the selected Bastion deployment and scaling configuration.
• Connection path: An administrator authenticates to Azure, opens a Bastion session, and reaches the VM through Azure-managed infrastructure.
  • Windows administration normally uses RDP on TCP port 3389.
  • Linux administration normally uses SSH on TCP port 22.
• Reduced exposure: Target VMs do not need public IP addresses or internet-facing RDP and SSH rules.
• Network controls: Network security groups can restrict management traffic to the Bastion subnet while denying direct external access.
• Credentials: Depending on the VM and Bastion capabilities, authentication can use passwords, SSH keys, or supported Microsoft Entra ID integration.
• Operational security: Session monitoring, diagnostic logs, conditional access, and privileged identity controls strengthen administrative oversight.
• Limitations: Bastion secures the connection path but does not replace VM patching, endpoint protection, strong authentication, or guest operating-system hardening.
• Example: A Linux VM with private address 10.20.1.4 can accept SSH from AzureBastionSubnet while its NSG denies inbound SSH from the internet.

III. Just-in-Time Access — Time-Bound Management Ports

A. Just-in-Time virtual machine access

Just-in-Time virtual machine access reduces the period during which VM management ports are reachable by opening them only after an authorized, time-limited request.

• Purpose: JIT limits brute-force attacks against ports such as RDP 3389 and SSH 22.
• Default state: Selected management ports remain blocked through NSG or Azure Firewall rules when no approved session exists.
• Request process:
  1. An authorized user requests access to a VM, port, source IP range, and duration.
  2. Microsoft Defender for Cloud verifies the user’s permissions and JIT policy.
  3. Azure creates or modifies a rule permitting the requested source until expiry.
  4. The temporary rule is removed or becomes ineffective when the approved period ends.
• Policy elements: A JIT policy identifies protected ports, allowed protocols, permitted source addresses, and maximum access duration.
• Authorization: Azure RBAC determines who may configure JIT and who may request access.
• Auditability: Defender for Cloud records requests, approvals, source addresses, and access periods for investigation and compliance.
• Bastion comparison:
  1. Azure Bastion: Provides a managed private route to a VM without requiring a VM public IP.
  2. JIT access: Temporarily changes network access rules; it may be used with Bastion or other controlled connection methods.
• Limitation: JIT minimizes port exposure but cannot protect compromised credentials after a session is authorized.

IV. Azure Kubernetes Service — Managed Container Orchestration

A. Azure Kubernetes Service (AKS)

Azure Kubernetes Service is a managed Kubernetes platform in which Azure operates the control plane while customers govern node pools, workloads, identities, policies, networking, and data protection.

• Responsibility boundary: Azure maintains the managed Kubernetes API and control-plane availability; customers secure container images, manifests, secrets, nodes, and applications.
• Cluster components:
  • Control plane: Hosts the Kubernetes API server, scheduler, and cluster-management services.
  • Node pools: Azure VMs or scale sets run kubelet, the container runtime, and workload pods.
  • Pods and services: Pods execute containers; Kubernetes Services expose stable network endpoints.
• Identity security: Microsoft Entra integration and Azure RBAC can control cluster access; managed identities allow workloads or cluster components to access Azure resources without stored passwords.
• Workload isolation: Namespaces, Kubernetes RBAC, network policies, security contexts, and separate node pools reduce unauthorized interaction.
• Pod hardening: Containers should run as non-root, drop unnecessary Linux capabilities, use read-only filesystems where practical, and enforce resource limits.
• Secret handling: Sensitive values should use Kubernetes Secrets with encryption protections or integrate with Azure Key Vault through supported workload identity and CSI mechanisms.
• Image security: Deployments should pull approved, vulnerability-scanned images from a controlled Azure Container Registry.
• Maintenance: Node-image upgrades, Kubernetes-version upgrades, autoscaling, backup planning, and Defender for Containers are customer governance concerns.
• Limitation: A managed control plane does not make insecure manifests, privileged containers, vulnerable images, or unrestricted network paths safe.

V. Network Segmentation — Restricting Communication Paths

A. Network isolation

Network isolation separates services into controlled trust zones and permits only the traffic required for legitimate workload communication.

• Virtual networks: Azure Virtual Network provides private IP address spaces such as 10.30.0.0/16, divided into subnets for application tiers or administrative boundaries.
• Network security groups: NSGs apply stateful allow and deny rules using source, destination, protocol, port, and priority.
  • A lower numeric priority is evaluated before a higher one.
  • A rule allowing HTTPS on TCP 443 can coexist with a later rule denying other inbound internet traffic.
• Private endpoints: Azure Private Link maps a supported platform service to a private IP in the consumer VNet, reducing dependence on public endpoints.
• Service endpoints: These preserve the service’s public endpoint but identify traffic as originating from an authorized VNet subnet.
• AKS isolation: Private clusters can restrict API-server exposure; network policies can control pod-to-pod and pod-to-external traffic.
• Registry isolation: ACR firewalls, private endpoints, and disabled public access can constrain image push and pull operations.
• Traffic inspection: Azure Firewall, application gateways, web application firewalls, and network virtual appliances can enforce centralized policy.
• DNS requirement: Private endpoints require correct private DNS resolution; an incorrect record may redirect clients to a public endpoint or break connectivity.
• Design limitation: Excessive segmentation increases routing, DNS, and operational complexity, so each permitted flow should have a documented business purpose.

VI. Observability — Detecting Faults and Threats

A. Monitor services

Azure monitoring services collect metrics, logs, traces, alerts, and security findings so operators can identify failures, suspicious behavior, and policy violations.

• Azure Monitor: Provides the principal platform for collecting and analyzing telemetry from Azure resources and applications.
• Metrics: Numerical time-series values, such as CPU percentage, request count, latency, or available memory, support near-real-time alerting.
• Logs: Log Analytics workspaces store structured records that can be queried with Kusto Query Language.
• Diagnostic settings: Resource logs and platform metrics can be routed to Log Analytics, Storage accounts, or Event Hubs.
• Application Insights: Captures application requests, dependencies, exceptions, traces, and distributed transaction data.
• Container insights: Monitors AKS nodes, controllers, pods, container logs, performance, and inventory.
• Microsoft Defender for Cloud: Produces security recommendations and workload-protection alerts for supported compute, container, storage, and registry resources.
• Microsoft Sentinel: Uses collected security data for SIEM analysis, detection rules, incidents, investigation, and automated response.
• Alert design: Action groups can notify operators or invoke automation when a metric threshold or log-query condition is met.
• Concrete query: The following KQL finds failed Azure administrative operations:

AzureActivity
| where ActivityStatusValue == "Failure"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup

• Limitation: Monitoring is effective only when logs are enabled, retained appropriately, protected from tampering, and connected to actionable response procedures.

VII. Identity Protection — Verifying Users and Workloads

A. Authentication services

Azure authentication services establish the identity of users, applications, and managed workloads before authorization controls determine what those identities may do.

• Microsoft Entra ID: Azure’s cloud identity service authenticates users, groups, service principals, applications, and managed identities.
• Authentication and authorization:
  1. Authentication: Proves identity, for example through a password, certificate, security key, or federated credential.
  2. Authorization: Evaluates permissions, such as the Reader, Contributor, or AcrPull Azure role.
• Multifactor authentication: MFA requires an additional factor and reduces reliance on passwords alone.
• Conditional Access: Policies can evaluate user risk, sign-in risk, device compliance, location, application, and authentication strength.
• Managed identities: Azure resources obtain Entra tokens without storing long-lived application secrets.
  • System-assigned identity: Its lifecycle is tied to one Azure resource.
  • User-assigned identity: Exists independently and can be associated with multiple resources.
• Workload identity: AKS workloads can federate Kubernetes service accounts with Entra identities, avoiding static credentials in pods.
• Azure RBAC: Role assignments combine a security principal, role definition, and scope such as subscription, resource group, or individual resource.
• Privileged Identity Management: PIM supports eligible, approval-based, and time-bound activation of privileged roles.
• Storage authentication: Entra ID with RBAC is generally preferable to broadly distributed storage account keys or shared access credentials.
• Limitation: Strong authentication cannot compensate for excessive role assignments; permissions must also be reviewed and minimized.

VIII. Azure Container Registry — Securing the Image Lifecycle

A. Manage Azure Container Registry

Managing Azure Container Registry involves controlling image publication, access, network reachability, vulnerability exposure, retention, and use by deployment platforms such as AKS.

• Registry structure: A registry contains repositories, and repositories contain image manifests identified by tags or immutable digests.
• Authentication: Human and workload access should use Microsoft Entra identities, service principals, or managed identities instead of the registry admin account.
• Role separation:
  • Pull access: The AcrPull role allows an identity to retrieve images.
  • Push access: The AcrPush role permits image upload and related repository operations.
  • Administration: Broader management roles should be restricted to registry operators.
• AKS integration: The AKS kubelet identity can receive pull permission so nodes retrieve private images without embedding registry credentials in Kubernetes manifests.
• Image reference: Production deployments should prefer a digest when exact artifact identity is required:

image: contoso.azurecr.io/payments@sha256:<digest>

• Network security: Private endpoints, selected-network rules, trusted-service configuration, and disabled public access can reduce registry exposure.
• Supply-chain controls: Build images from trusted bases, scan for vulnerabilities, generate provenance where supported, and promote artifacts through controlled environments.
• Tag governance: Mutable tags such as latest can change unexpectedly; versioned tags and digest pinning improve reproducibility.
• Lifecycle management: Retention policies, repository permissions, geo-replication where required, and deletion controls reduce stale or unauthorized content.
• Audit and response: Registry events, activity logs, Defender findings, and deployment inventories help identify who published an image and where it is running.
• Limitation: A private registry protects storage and distribution, but it does not guarantee that an image is vulnerability-free or trustworthy.