Pod Sandboxing with Azure Kubernetes Service (AKS)

To help secure and protect your container workloads from untrusted or potentially malicious code, AKS now includes a mechanism called Pod Sandboxing. Pod Sandboxing provides an isolation boundary between the container application and the shared kernel and compute resources of the container host such as CPU, memory, and networking. Applications are spun up in isolated, lightweight pod virtual machines (VMs). Pod Sandboxing complements other security measures or data protection controls with your overall architecture to help you meet regulatory, industry, or governance compliance requirements for securing sensitive information.

This article helps you understand this new feature, and how to implement it.

Prerequisites

The Azure CLI version 2.44.1 or later. Run az --version to find the version, and run az upgrade to upgrade the version. If you need to install or upgrade, see Install Azure CLI.
AKS supports Pod Sandboxing on Kubernetes version 1.27.0 and higher.
To manage a Kubernetes cluster, use the Kubernetes command-line client kubectl. Azure Power Shell comes with kubectl. You can install kubectl locally using the az aks install-cli command.

Limitations

The following are constraints applicable to Pod Sandboxing:

Kata containers might not reach the IOPS performance limits that traditional containers can reach on Azure Files and high-performance local SSD.
Microsoft Defender for Containers doesn't support assessing Kata runtime pods.
Kata host-network access isn't supported. It isn't possible to directly access the host networking configuration from within the VM.
CPU and memory allocation with Pod Sandboxing has other considerations compared to runc. Reference the memory management sections in the considerations page.

How it works

Pod Sandboxing on AKS builds on top of the open-source Kata Containers project. Kata Containers running on the Azure Linux container host for AKS provides VM based isolation and a separate kernel for each pod. Pod Sandboxing allows users to allocate resources for each pod and doesn't share them with other Kata Containers or namespace containers running on the same host.

The solution architecture is based on the following main components:

The Azure Linux container host for AKS
Microsoft Hyper-V Hypervisor
Open-source Cloud-Hypervisor Virtual Machine Monitor (VMM)
Integration with Kata Container for the runtime

Deploying Pod Sandboxing using Kata Containers is similar to the standard containerd workflow to deploy containers. Clusters with Pod Sandboxing enabled come with a specific runtime class that can be referenced in a pod manifest (runtimeClassName: kata-vm-isolation).

To use this feature with a pod, the only difference is to add the runtimeClassName, kata-vm-isolation to the pod spec. When a pod uses the kata-vm-isolation runtimeClass, the hypervisor spins up a lightweight virtual machine with its own kernel, for the workload to operate in.

Deploy new cluster

Perform the following steps to deploy an Azure Linux AKS cluster using the Azure CLI.

Create an AKS cluster using the az aks create command and specifying the following parameters:
- --workload-runtime: Specify KataVmIsolation to enable the Pod Sandboxing feature on the node pool. With this parameter, these other parameters should satisfy the following requirements. Otherwise, the command fails and reports an issue with the corresponding parameters.
- --os-sku: AzureLinux. Only the Azure Linux os-sku supports this feature.
- --node-vm-size: Any Azure VM size that is a generation 2 VM and supports nested virtualization works. For example, Dsv3 VMs.
The following example creates a cluster named myAKSCluster with one node in the myResourceGroup:
```
az aks create
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --os-sku AzureLinux \
    --workload-runtime KataVmIsolation \
    --node-vm-size Standard_D4s_v3 \
    --node-count 3 \
    --generate-ssh-keys
```
Run the following command to get access credentials for the Kubernetes cluster. Use the az aks get-credentials command and replace the values for the cluster name and the resource group name.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```
List all Pods in all namespaces using the kubectl get pods command.
```
kubectl get pods --all-namespaces
```

Deploy to an existing cluster

To use this feature with an existing AKS cluster, the following requirements must be met:

Verify the cluster is running Kubernetes version 1.27.0 and higher.

Use the following command to enable Pod Sandboxing by creating a node pool to host it.

Add a node pool to your AKS cluster using the az aks nodepool add command. Specify the following parameters:
- --resource-group: Enter the name of an existing resource group to create the AKS cluster in.
- --cluster-name: Enter a unique name for the AKS cluster, such as myAKSCluster.
- --name: Enter a unique name for your clusters node pool, such as nodepool2.
- --workload-runtime: Specify KataVmIsolation to enable the Pod Sandboxing feature on the node pool. Along with the --workload-runtime parameter, these other parameters shall satisfy the following requirements. Otherwise, the command fails and reports an issue with the corresponding parameter.
  - --os-sku: AzureLinux. Only the Azure Linux os-sku supports this feature.
  - --node-vm-size: Any Azure VM size that is a generation 2 VM and supports nested virtualization works. For example, Dsv3 VMs.
The following example adds a node pool to myAKSCluster with one node in nodepool2 in the myResourceGroup:
```
az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataVmIsolation --node-vm-size Standard_D4s_v3
```

Run the az aks update command to enable pod sandboxing on the cluster.

az aks update --name myAKSCluster --resource-group myResourceGroup

Deploying your applications

With Pod Sandboxing, you can deploy a mix of "normal" pods that don't utilize the Kata runtime alongside Kata pods that do utilize the runtime. The main difference between the two, when deploying, lies in the fact that a Kata pod has the line runtimeClassName: kata-vm-isolation in its spec.

Deploy an application with the Kata runtime

To deploy a pod with the Kata runtime on your AKS cluster, perform the following steps.

Create a file named kata-app.yaml to describe your kata pod, and then paste the following manifest.

kind: Pod
apiVersion: v1
metadata:
  name: isolated-pod
spec:
  runtimeClassName: kata-vm-isolation
  containers:
  - name: kata
    image: mcr.azk8s.cn/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

The value for runtimeClassNameSpec is kata-vm-isolation.

Deploy the Kubernetes pod by running the kubectl apply command and specify your kata-app.yaml file:
```
kubectl apply -f kata-app.yaml
```
The output of the command resembles the following example:
```
pod/isolated-pod created
```

(Optional) Verify Kernel Isolation configuration

If you would like to verify the difference between the kernel of a Kata and non-Kata pod, you can spin up another workload that doesn't have the Kata runtime.

kind: Pod
apiVersion: v1
metadata:
  name: normal-pod
spec:
  containers:
  - name: non-kata
    image: mcr.azk8s.cn/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

To access a container inside the AKS cluster, start a shell session by running the kubectl exec command. In this example, you're accessing the container inside kata-pod.
```
kubectl exec -it isolated-pod -- /bin/sh
```
Kubectl connects to your cluster, runs /bin/sh inside the first container within isolated-pod, and forwards your terminal's input and output streams to the container's process. You can also start a shell session to the container hosting the non-Kata pod to see the differences.
After starting a shell session to the container from kata-pod, you can run commands to verify that the kata container is running in a pod sandbox. Notice that it has a different kernel version compared to the non-Kata container outside the sandbox.

To see the kernel version run the following command:
```
uname -r
```
The following example resembles output from the pod sandbox kernel:
```
[user]/# uname -r
6.6.96.mshv1
```
Start a shell session to the container from normal-pod to verify the kernel output:
```
kubectl exec -it normal-pod -- /bin/bash
```
To see the kernel version run the following command:
```
uname -r
```
The following example resembles output from the VM that's running normal-pod, which is a different kernel than the Kata pod running within the pod sandbox:
```
6.6.100.mshv1-1.azl3
```

Cleanup

When you're finished evaluating this feature, to avoid Azure charges, clean up your unnecessary resources. If you deployed a new cluster as part of your evaluation or testing, you can delete the cluster using the az aks delete command.

az aks delete --resource-group myResourceGroup --name myAKSCluster

If you deployed Pod Sandboxing on an existing cluster, you can remove the pods using the kubectl delete pod command.

kubectl get pods
kubectl delete pod <kata-pod-name>

Next steps

Learn more about Azure Dedicated hosts for nodes with your AKS cluster to use hardware isolation and control over Azure platform maintenance events.
To further explore Pod Sandboxing isolation and explore workload scenarios, try out the Pod Sandboxing labs.

Last updated on 2025-11-27