Run Confidential Workloads in AKS (2026)

Confidential computing in AKS doesn’t encrypt your data at rest or in transit; it encrypts your data while it’s being processed inside the CPU.

Here’s how you can run confidential workloads in Azure Kubernetes Service (AKS).

The Core Idea: Hardware-Based Isolation

Confidential computing relies on hardware features within the CPU itself to create a secure, isolated environment called a Trusted Execution Environment (TEE). In AKS, this is primarily achieved using AMD’s Secure Encrypted Virtualization (SEV) technology.

When you deploy a confidential VM in Azure for AKS, the VM’s memory is encrypted by the AMD EPYC processor. This means even the hypervisor (the software managing the VMs) or the cloud provider’s infrastructure can’t access the data in that VM’s memory. For AKS, this translates to encrypting the memory used by your Kubernetes nodes.

Setting Up a Confidential AKS Cluster

Choose the Right VM Size: Not all VM sizes support confidential computing. You need to select an Azure VM series that has AMD EPYC processors and supports SEV. As of my last update, these are typically found in the DCasv5 and ECasv5 series. For example, Standard_DC4_8sv2 or Standard_EC4sv5.
Create the AKS Cluster: When you create your AKS cluster, you’ll specify the agent pool to use these confidential VM sizes.
```
az aks nodepool add \
    --resource-group <your-resource-group> \
    --cluster-name <your-aks-cluster-name> \
    --name confidentialpool \
    --node-vm-size Standard_DC4_8sv2 \
    --node-count 1 \
    --os-type Linux \
    --mode User
```
This command adds a new node pool named confidentialpool using the Standard_DC4_8sv2 VM size, which is a confidential computing-enabled VM.
Deploy Your Workload: You can then deploy your containerized applications to this node pool. Kubernetes will schedule pods onto nodes within the confidentialpool.

What Happens Under the Hood?

When a pod is scheduled onto a confidential node:

Memory Encryption: The AKS node’s operating system and the Kubernetes components (like the kubelet) run normally. However, the memory pages allocated to your application’s pods are encrypted by the CPU’s SEV hardware.
TEE for Pods: While the entire VM is encrypted, the primary benefit for your workload is that the memory it consumes is protected from the host OS and hypervisor. If you’re using specific confidential computing SDKs (like Azure Confidential Computing SDKs), your application can leverage the TEE to perform operations on sensitive data, ensuring that even the node administrator cannot see that data in plaintext.
Attestation: A crucial aspect of confidential computing is attestation. This is a process where your application can cryptographically verify that it’s running in a genuine TEE on trusted hardware. You can implement this in your application code to ensure it hasn’t been tampered with and is running in the intended secure environment.

Example: Deploying a Simple Application

Let’s say you have a simple web application that processes sensitive data. You’d typically build a Docker image for it.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: confidential-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: confidential-app
  template:
    metadata:
      labels:
        app: confidential-app
    spec:
      containers:
      - name: my-app
        image: <your-docker-repo>/confidential-app:latest
        ports:
        - containerPort: 80
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: agentpool
                operator: In
                values:
                - confidentialpool # This is key to target your confidential nodes

The nodeSelectorTerms with agentpool: confidentialpool ensures this deployment only runs on nodes in your designated confidential node pool.

The Nuance: Beyond Just Encryption

While memory encryption is the foundation, the real power of confidential computing for your applications comes when you design them to take advantage of the TEE. This often involves:

Secure Key Management: Using hardware security modules (HSMs) or secure enclaves to store and manage encryption keys used by your application.
Data Processing within the TEE: Designing your application so that sensitive data is decrypted, processed, and re-encrypted only within the secure memory boundaries of the TEE.
Attestation Integration: Implementing the attestation process to prove the integrity and origin of the TEE to external parties or other services.

Without these application-level changes, deploying to a confidential node pool primarily protects your data from the infrastructure. To protect it from your own application code (if compromised) or other aspects of the cluster, you need to leverage the TEE’s capabilities more directly.

The next step after running confidential workloads is often exploring how to perform remote attestation to verify the integrity of your TEE and workload to other services.