Unit 3: Secure Compute and Storage - Subjective Questions

Azure Bastion is a fully managed platform service that provides secure RDP and SSH connectivity to Azure virtual machines through the Azure portal or supported native clients.

• It is deployed inside a dedicated subnet named AzureBastionSubnet within an Azure virtual network.
• Administrators connect to virtual machines using their private IP addresses.
• Virtual machines do not require public IP addresses for administrative access.
• RDP and SSH traffic is carried through an encrypted TLS connection over port 443.
• The service reduces exposure to port scanning, brute-force attacks, and other internet-based threats.
• Microsoft manages the Bastion infrastructure, including maintenance and platform availability.

Thus, Azure Bastion provides a controlled entry point for managing virtual machines without exposing management ports directly to the public internet.

The Azure Bastion connection flow involves the following components and steps:

1. Deployment: Azure Bastion is deployed in the target virtual network using the dedicated AzureBastionSubnet.
2. User authentication: The administrator signs in to Azure and is authorized through Azure role-based access control.
3. Secure connection: The user's browser or supported native client establishes a TLS-encrypted session with Azure Bastion over TCP port 443.
4. Private routing: Bastion connects to the target virtual machine through its private IP address.
5. Management protocol: RDP is used for Windows virtual machines, while SSH is generally used for Linux virtual machines.
6. Network enforcement: Network security groups and routing rules must permit the required traffic between Bastion and the target virtual machine.

The resulting path can be represented as:

Administrator TLS over port 443 Azure Bastion private RDP or SSH virtual machine.

This architecture keeps the virtual machine's management interface isolated from the public internet.

Just-in-Time (JIT) virtual machine access is a security feature in Microsoft Defender for Cloud that limits the time during which management ports of a virtual machine are accessible.

Its working process is:

• Sensitive ports such as 22 for SSH, 3389 for RDP, and management ports such as 5985 or 5986 are normally blocked by network security group or Azure Firewall rules.
• An authorized user requests access to a specific virtual machine and port.
• The request includes the source IP address and required access duration.
• Azure verifies the user's permissions and the configured JIT policy.
• If approved, Azure temporarily creates or modifies a rule permitting access from the approved source.
• When the approved duration expires, the temporary access is automatically removed.

JIT access reduces the attack surface by ensuring that administrative ports remain closed except during explicitly authorized maintenance periods.

Azure Bastion and JIT access both protect virtual machine management interfaces, but they use different mechanisms.

The two services can complement each other. Bastion provides private administrative connectivity, while JIT policies add time-bound control when direct or alternative management access must be permitted.

Azure Kubernetes Service (AKS) is a managed Kubernetes service used to deploy, scale, and operate containerized applications in Azure.

Its major components include:

• Control plane: Managed by Azure and responsible for the Kubernetes API server, scheduling, and cluster-state management.
• Node pools: Groups of Azure virtual machines that run container workloads.
• Pods: The smallest deployable Kubernetes units, containing one or more containers.
• Deployments and StatefulSets: Controllers that manage application replicas and workload state.
• Services and ingress: Resources that provide internal or external network access to applications.
• Storage classes and persistent volumes: Resources that provide durable storage to workloads.
• Microsoft Entra integration: Provides identity-based cluster authentication and authorization.
• Azure Monitor integration: Collects cluster metrics, logs, and diagnostic information.
• Azure Container Registry integration: Enables controlled access to private container images.

AKS reduces operational overhead because Azure manages the Kubernetes control plane and provides integration with other Azure security and management services.

Under the shared responsibility model, Microsoft and the customer are responsible for different parts of AKS security.

Microsoft responsibilities:

• Operating and maintaining the managed Kubernetes control plane.
• Protecting the physical datacenters, hardware, and core Azure infrastructure.
• Maintaining availability of the managed AKS service.
• Applying platform-level updates to managed service components.

Customer responsibilities:

• Securing container images and removing known vulnerabilities.
• Configuring cluster authentication and Kubernetes authorization.
• Applying network policies and controlling ingress and egress traffic.
• Updating node images and selecting appropriate Kubernetes upgrade schedules.
• Protecting secrets, certificates, and application data.
• Defining pod security settings, resource limits, and workload identities.
• Monitoring audit logs, runtime events, and security alerts.
• Backing up application state and testing recovery procedures.

Using a managed service does not automatically secure workloads. The customer must secure cluster configuration, identities, networks, images, and applications.

A defense-in-depth strategy protects AKS across multiple security layers:

• Identity layer: Integrate AKS with Microsoft Entra ID, use Kubernetes RBAC, apply least privilege, and prefer workload identity over stored credentials.
• Network layer: Use private clusters where appropriate, restrict API server access, apply network policies, control ingress, and filter outbound traffic.
• Image layer: Store images in a private Azure Container Registry, scan images, sign trusted artifacts, and avoid mutable production tags.
• Pod layer: Run containers as non-root, use read-only file systems where possible, drop unnecessary Linux capabilities, and enforce security standards.
• Secret layer: Keep secrets in Azure Key Vault and access them through managed identities or workload identity.
• Node layer: Patch node images, upgrade supported Kubernetes versions, and separate sensitive workloads into dedicated node pools.
• Monitoring layer: Enable Azure Monitor, Container Insights, Kubernetes audit logs, and Microsoft Defender for Containers.
• Governance layer: Use Azure Policy to audit or deny noncompliant cluster and workload configurations.

No single control is sufficient. Combined controls limit initial compromise, lateral movement, privilege escalation, and data loss.

Network isolation is the separation of resources and traffic so that only explicitly authorized systems can communicate with protected services.

Important Azure controls include:

• Virtual networks: Establish private network boundaries for Azure resources.
• Subnets: Separate workloads by function, sensitivity, or trust level.
• Network security groups: Permit or deny inbound and outbound traffic using stateful rules.
• Application security groups: Apply network rules to logical groups of virtual machines.
• Private endpoints: Assign private virtual-network addresses to supported platform services such as Storage and Azure Container Registry.
• Service endpoints: Extend virtual-network identity to supported Azure services while traffic remains on the Azure backbone.
• Azure Firewall: Provides centralized filtering, threat intelligence, and traffic logging.
• User-defined routes: Direct traffic through approved security appliances or inspection points.
• AKS network policies: Restrict communication between Kubernetes pods.
• Public network access controls: Disable unnecessary public endpoints.

Effective isolation follows a default-deny principle and explicitly permits only required communication paths.

Both features restrict access to Azure platform services, but they operate differently.

A private endpoint is generally preferred when a resource must be reachable through a private IP address. Service endpoints may be suitable when simpler subnet-based restrictions meet the security requirements.

These controls provide complementary protection at different scopes:

• Network security groups (NSGs): Filter inbound and outbound traffic at the subnet or network-interface level. Rules use source, destination, protocol, port, and priority. NSGs are suitable for controlling communication between Azure network segments and resources.
• Azure Firewall: Provides centralized network and application filtering across multiple subnets or virtual networks. It supports threat-intelligence filtering, network rules, application rules, destination network address translation, and detailed logs.
• AKS network policies: Control traffic between Kubernetes pods and namespaces. They can define which pods may send or receive traffic, supporting microsegmentation inside the cluster.

A layered design may use an NSG to protect the AKS subnet, Azure Firewall to inspect cluster egress, and network policies to prevent unauthorized pod-to-pod communication. Each control protects a different boundary, so one does not completely replace the others.

Azure provides several integrated monitoring services:

• Azure Monitor: The central platform for collecting, analyzing, and responding to metrics and logs.
• Log Analytics workspace: Stores log data and supports analysis using Kusto Query Language.
• Application Insights: Monitors application performance, requests, dependencies, exceptions, and availability.
• Container Insights: Collects AKS node, controller, pod, container, performance, and inventory information.
• Network Watcher: Provides network diagnostics such as connection troubleshoot, packet capture, IP flow verification, and topology views.
• Activity Log: Records subscription-level control-plane events, including resource creation, modification, and deletion.
• Resource logs: Capture service-specific operations when diagnostic settings are enabled.
• Microsoft Defender for Cloud: Produces security recommendations, posture assessments, and threat alerts.
• Azure Service Health: Reports Azure incidents, planned maintenance, and service advisories relevant to subscribed resources.

Together, these services support availability monitoring, troubleshooting, performance analysis, auditing, and security detection.

The three telemetry types serve different purposes:

• Metrics: Numerical, time-series measurements collected at regular intervals. Examples include CPU percentage, network bytes, request count, and storage latency. Metrics are suitable for dashboards and fast threshold-based alerts.
• Resource logs: Detailed records generated by an individual Azure resource or service. Examples include firewall traffic, Key Vault access, AKS control-plane events, and storage operations. They are useful for troubleshooting and security investigations.
• Activity Log: Subscription-level control-plane records that show who performed a management operation, what operation was attempted, when it occurred, and whether it succeeded. It is useful for auditing resource configuration changes.

For example, a high CPU metric can detect virtual machine overload, an AKS audit log can identify an unauthorized Kubernetes request, and the Activity Log can show who changed the cluster configuration.

A monitoring and alerting strategy for a security-sensitive AKS application should include:

1. Centralized collection: Send AKS control-plane logs, audit logs, node logs, container logs, and relevant network logs to a Log Analytics workspace.
2. Performance visibility: Enable Container Insights to observe node utilization, pod restarts, failed containers, and resource pressure.
3. Application monitoring: Use Application Insights for request rates, latency, dependency failures, exceptions, and availability tests.
4. Security monitoring: Enable Microsoft Defender for Containers for image, configuration, and runtime recommendations or alerts.
5. Critical alerts: Create alerts for unauthorized API requests, repeated authentication failures, abnormal pod creation, excessive restarts, unavailable replicas, and high CPU or memory pressure.
6. Notification routing: Use action groups to notify the operations or security team and trigger approved automation.
7. Retention and access: Retain logs according to compliance requirements and restrict workspace access using role-based access control.
8. Response procedures: Associate each high-severity alert with an incident owner and a documented response process.

The strategy must monitor both application reliability and security because a compromise can first appear as an operational anomaly.

These services provide related but distinct identity controls:

• Microsoft Entra ID: Authenticates users, groups, service principals, and workload identities. It supports controls such as multifactor authentication and Conditional Access.
• Managed identities: Provide Azure resources with automatically managed identities. Applications can obtain tokens for supported Azure services without storing passwords or client secrets in code.
• Azure role-based access control (Azure RBAC): Determines which management-plane or supported data-plane actions an identity may perform at a management group, subscription, resource group, or resource scope.
• Kubernetes RBAC: Controls actions on Kubernetes resources inside an AKS cluster and can be integrated with Microsoft Entra identities.

A secure design authenticates the identity through Microsoft Entra ID, uses managed identity or workload identity for applications, and assigns only the minimum required role at the narrowest practical scope.

Authentication verifies the identity making a request, while authorization determines what that authenticated identity may do.

In AKS:

• Authentication can be integrated with Microsoft Entra ID so that users authenticate using centrally managed organizational identities.
• Service and application authentication should use AKS workload identity or managed identities instead of static credentials.
• Authorization can be implemented through Kubernetes RBAC or Azure RBAC for Kubernetes authorization.
• Roles define permitted actions, while role bindings assign those permissions to users, groups, or service accounts.
• Namespace-scoped role bindings should be used when access is needed only within a specific namespace.
• Cluster-wide administrative roles should be tightly restricted.
• Privileged access should be protected using multifactor authentication, Conditional Access, and time-bound elevation where available.
• Audit logging should be enabled to record access attempts and administrative operations.

Secure implementation requires both strong identity verification and least-privilege permission assignment.

Azure Container Registry (ACR) is a managed private registry for storing and distributing container images and related Open Container Initiative artifacts.

In a secure deployment pipeline, ACR can:

• Store organization-approved images in a controlled registry.
• Authenticate developers, pipelines, and deployment platforms through Microsoft Entra ID, service principals, managed identities, or workload identities.
• Apply role-based access control to separate image push, pull, and management permissions.
• Integrate with AKS so cluster nodes can pull private images.
• Use private endpoints and firewall rules to restrict network access.
• Support image import and automated build workflows.
• Retain metadata needed for image versioning and traceability.
• Work with security tools that identify vulnerable image packages.
• Use content-trust mechanisms and immutable release practices to reduce image tampering risks.

ACR acts as the controlled distribution point between image creation and container deployment.

Least-privilege access to ACR should be implemented as follows:

• Use Microsoft Entra identities instead of sharing the registry administrator account.
• Keep the admin user disabled unless a narrowly justified compatibility requirement exists.
• Grant image-pull permission only to identities that deploy or run images.
• Grant image-push permission only to trusted build pipelines and authorized publishers.
• Separate registry administration from artifact publishing and consumption duties.
• Assign roles at the narrowest supported scope and remove unused assignments.
• Use managed identity or AKS integration for cluster access instead of embedding registry passwords in Kubernetes secrets.
• Use repository-scoped permissions where supported to isolate teams and applications.
• Protect privileged users through multifactor authentication and Conditional Access.
• Review access logs and role assignments periodically.

This approach limits the impact of a compromised user, workload, or pipeline by preventing it from performing unnecessary registry operations.

A secure AKS-to-ACR integration generally includes these steps:

1. Create or identify the registry: Use an Azure Container Registry in an approved subscription and region.
2. Choose the identity: Use the appropriate AKS kubelet managed identity or another supported workload identity.
3. Assign pull permission: Grant the identity only the role or repository permission required to pull approved images.
4. Attach the registry: Configure AKS integration with ACR or create the equivalent role assignment explicitly.
5. Restrict networking: Use firewall rules, selected networks, or a private endpoint when public registry access is not required.
6. Configure DNS: Ensure the cluster can resolve the registry's private endpoint correctly when Private Link is used.
7. Reference exact images: Configure workloads to use the correct registry name, repository, and preferably immutable digest.
8. Validate access: Deploy a test workload and confirm that the image can be pulled without stored registry credentials.
9. Enable monitoring: Collect registry login, repository, and network diagnostics where supported.

The key security outcome is that AKS pulls images using an identity with limited permissions rather than a long-lived shared password.

Secure image lifecycle management controls artifacts from creation to retirement:

• Tagging: Use consistent tags for versions, environments, and release stages. Avoid relying only on a mutable tag such as latest.
• Digests: Deploy production images by digest where practical so the referenced content cannot silently change.
• Immutability: Lock important release artifacts or use policies and processes that prevent approved tags from being overwritten.
• Scanning: Scan images during build and continuously reassess stored images as new vulnerabilities are discovered.
• Promotion: Promote the same tested image artifact between environments instead of rebuilding it separately for production.
• Retention: Define how long untagged manifests, development images, and release artifacts must be retained.
• Cleanup: Use retention features, purge tasks, or controlled automation to remove obsolete artifacts.
• Deletion protection: Restrict delete permissions and protect critical repositories from accidental or malicious removal.
• Auditability: Record the image digest, source revision, build identity, and deployment history.

These practices improve reproducibility, reduce storage waste, and lower the risk of deploying altered or vulnerable images.

A suitable architecture would apply defense in depth across the complete workload:

• Compute: Deploy AKS as a private cluster and use dedicated node pools for workloads with different security requirements. Apply supported Kubernetes versions, hardened pod settings, and regular node-image upgrades.
• Administration: Use Azure Bastion to reach a management virtual machine through private addressing. Apply JIT access to any exceptional management path that requires temporary port access.
• Registry: Store images in ACR, scan them before release, and grant the AKS kubelet identity only image-pull permission. Reference approved images by digest.
• Storage: Use Azure Storage private endpoints, disable unnecessary public network access, enforce secure transfer, and use managed identities for data access.
• Network: Separate Bastion, management, AKS, and private-endpoint resources into appropriate subnets. Apply NSGs, Azure Firewall egress control, user-defined routes, and AKS network policies.
• Identity: Integrate administrators with Microsoft Entra ID, require multifactor authentication, apply least-privilege Azure and Kubernetes RBAC, and use workload identity for applications.
• Secrets: Store sensitive values in Azure Key Vault and retrieve them through identity-based access.
• Monitoring: Send AKS, ACR, Storage, Firewall, Key Vault, and Activity Log data to Azure Monitor and Log Analytics. Enable Container Insights and Microsoft Defender security protections.
• Response: Configure alerts and action groups for unauthorized access, suspicious image activity, policy violations, and workload failures.

This design eliminates unnecessary public exposure and ensures that every access path is identity-aware, restricted, logged, and reviewable.