9.3 Container & Azure Kubernetes Service (AKS) Security

6.3 Container & Azure Kubernetes Service (AKS) Security

Containerized application deployments in Azure Kubernetes Service (AKS) demand defense-in-depth across multiple abstraction layers: the Kubernetes API control plane, node infrastructure, container network communication, workload identity, and image registry pipelines. Securing AKS involves protecting both cluster-level infrastructure and in-cluster workload runtimes.

---

AKS Cluster Security & Control Plane Isolation

Securing an Azure Kubernetes Service deployment requires isolating management endpoints and managing administrative identity boundaries.

Public vs. Private AKS Clusters

• Public AKS Clusters: The Kubernetes API server control plane is assigned a public FQDN (*.hcp.<region>.azmk8s.io). Although protected by TLS and Kubernetes RBAC, the API server endpoint remains accessible over the public internet.
• Private AKS Clusters: The Kubernetes API server is assigned a private IP address within the cluster's virtual network via Azure Private Link. All API management network traffic is isolated from the public internet. Administrative access requires routing through a peered virtual network, an Azure VPN Gateway, ExpressRoute, or an internal Azure Bastion host.

+-----------------------------------------------------------------------------------+
|                         PRIVATE AKS CLUSTER TOPOLOGY                              |
+-----------------------------------------------------------------------------------+
|  Peered Admin VNet / VPN  ---> [Private Link] ---> Private API Server (10.0.0.5)  |
|                                                           |                       |
|                                                           v                       |
|  Internal VNet Subnet (10.240.0.0/16) ---------> AKS Worker Nodes & Pods          |
+-----------------------------------------------------------------------------------+

Microsoft Entra ID Integration & Kubernetes RBAC

Integrating Microsoft Entra ID with AKS replaces static, shared cluster administrator credentials (kubeconfig local admin tokens) with enterprise identity governance:

• Entra Group Binding: Kubernetes RoleBinding and ClusterRoleBinding manifests map Kubernetes roles directly to Microsoft Entra ID Object IDs (security groups).
• Disabling Local Accounts: Administrators can explicitly disable local cluster admin accounts using --disable-local-accounts. This mandates Entra ID authentication for every kubectl request.
• Conditional Access Integration: API server logins enforce Entra ID Conditional Access policies, including phishing-resistant MFA and device compliance checks.

Pod Network Policies: Azure CNI Policy vs. Calico

By default, all pods within an AKS cluster can communicate with all other pods across namespaces. Network policies establish micro-segmentation boundaries:

• Azure CNI Network Policy: Microsoft's native network policy implementation. Integrates directly with Azure Virtual Network controls; rules are processed efficiently at the Linux kernel layer via iptables or eBPF.
• Calico Network Policy: A widely adopted open-source network policy engine. Supports advanced features including global network policies, application-layer HTTP rules, and cross-platform policy enforcement across both Linux and Windows node pools.

---

Pod Security Standards & Azure Policy for AKS

Preventing compromised container workloads from escaping host namespaces or compromising worker nodes requires strict runtime privilege restriction.

Kubernetes Pod Security Standards Tiers

Kubernetes defines three progressive security levels for pod workloads:

1. Privileged: Unrestricted permissions. Intended only for system-level infrastructure pods (e.g., CNI plugins, storage drivers).
2. Baseline: Default minimal restriction. Prevents known privilege escalations (e.g., host network sharing, host PID namespace access).
3. Restricted: Highly hardened configuration. Enforces strict best practices:
   • Disallows root execution (runAsNonRoot: true)
   • Restricts volume types (disallows hostPath mounts)
   • Drops all Linux capabilities except explicitly allowed ones (drop: ["ALL"])
   • Forces read-only root filesystems

Azure Policy Add-on for AKS

The Azure Policy Add-on for AKS integrates Open Policy Agent (OPA) Gatekeeper with the Kubernetes API server admission controller. Security administrators assign built-in Azure Policy definitions that evaluate pod manifests before creation, automatically auditing or denying non-compliant workloads.

---

Secrets Store CSI Driver Integration with Key Vault

Storing sensitive credentials as native Kubernetes Secrets presents operational security risks: native secrets are merely base64-encoded strings stored in etcd, vulnerable to unauthorized access if etcd or cluster RBAC is compromised.

+-----------------------------------------------------------------------------------+
|              SECRETS STORE CSI DRIVER WITH WORKLOAD IDENTITY                      |
+-----------------------------------------------------------------------------------+
|  Application Pod (Pod Spec Mounts Volume)                                         |
|        |                                                                          |
|        v                                                                          |
|  Secrets Store CSI Driver  <---> Entra Workload Identity (Federated Credential)   |
|        |                                                                          |
|        v (Private Endpoint)                                                       |
|  Azure Key Vault (Secret retrieved directly into memory volume mount)             |
+-----------------------------------------------------------------------------------+

Secrets Store CSI Driver Architecture

The Secrets Store CSI Driver allows AKS to mount secrets, keys, and certificates stored in Azure Key Vault directly as file system volume mounts inside application pods:

• No Stored Credentials: Uses Microsoft Entra Workload Identity to establish a federated identity relationship between the Kubernetes service account and a Managed Identity authorized in Key Vault.
• In-Memory Volume Mounts: Secret payloads exist only as temporary in-memory volume files (tmpfs) attached to the running container lifecycle.
• Auto-Rotation: Automatically synchronizes updated secret versions from Key Vault into the mounted pod volume without requiring pod restarts.

---

Azure Container Registry (ACR) Security

Azure Container Registry (ACR) acts as the central supply-chain repository for container images. Securing ACR requires enforcing network isolation, image integrity, and vulnerability scanning.

ACR Network Hardening & Dedicated Data Endpoints

• Disable Public Access: Set publicNetworkAccess = "Disabled" on the ACR instance.
• Private Endpoints: Route registry login (<registry-name>.azurecr.io) over Azure Private Link.
• Dedicated Data Endpoints: Container images consist of manifest files and underlying data storage blobs. Enabling Dedicated Data Endpoints creates regional data endpoints (<registry-name>.<region>.data.azurecr.io), allowing network firewalls to restrict traffic strictly to container storage blobs without allowing wide regional storage ranges.

Content Trust & Image Signing

Content Trust enables digital signature verification for container images using Docker Notary or ORAS (OCI Registry as Storage):

• Developers or CI/CD pipelines sign container images using a private key during docker push.
• AKS policy enforcement engines verify signatures prior to image pull, preventing unsigned or tampered images from executing in cluster environments.

Vulnerability Scanning with Defender for Containers

Microsoft Defender for Containers performs automated, agentless scanning of container images pushed to ACR:

• On-Push Scanning: Scans container OS packages and language libraries (Python, Node, Go) for known CVEs immediately upon upload.
• Continuous Rescanning: Continuously rescans published images when new CVE databases are released to identify newly discovered zero-day vulnerabilities.