Confidential AI ･ Provisioning a confidential cluster on Azure (AKS)

Stand up a single-node AKS cluster backed by a confidential node pool — a managed Kubernetes cluster ready for c8s, with no VM to build or Kubernetes to install by hand.

The simplest way to get a Confidential Kubernetes cluster on Azure is a managed AKS cluster with a confidential VM node pool: Azure runs the control plane and gives you nodes that are already confidential VMs, so there is no VM to build and no Kubernetes to install by hand. You point kubectl at it from your laptop and install c8s. The AKS control plane is managed by Azure and — like any control plane — stays outside the trust boundary; the confidential node pool is your node-as-CVM. When the cluster is up, continue to Install c8s.

New to c8s? Skim the overview and the runtime model first — on Azure you run the node-as-CVM shape. This page assumes only basic Azure and kubectl familiarity.

Prerequisites

On your laptop:

An Azure subscription, with the Azure CLI installed and logged in (az login).
kubectl — if you don't have it, az aks install-cli installs a compatible build.

Confidential VM sizes

AKS confidential node pools use the same AMD SEV-SNP DCas_v5 family as standalone Azure confidential VMs. Pick a node size by workload:

SKU	vCPU	Typical use
`Standard_DC2as_v5`	2	smallest — quota/cost-friendly smoke tests
`Standard_DC4as_v5`	4	a comfortable single-node dev cluster
`Standard_DC48as_v5`	48	a large single node

Confidential VM sizes exist only in some regions (for example northeurope); check with az vm list-skus --location <REGION> --size Standard_DC before you provision.

Azure also offers Intel TDX confidential VMs (the DCes_v5 / ECes_v5 family), and c8s supports them on the same vTPM attestation path. The choice is a second install flag, --hardware-platform — see Next: install c8s. Everything else in this guide is identical; substitute the TDX size for the DCas_v5 one.

Step by step

1. Create the AKS cluster with a confidential node pool

Choosing a DCas_v5 node size makes the pool a SEV-SNP confidential VM node pool (a DCes_v5 / ECes_v5 size makes it an Intel TDX one) — each node boots as a CVM with a vTPM. --node-count 1 keeps it single-node for a dev cluster.

az group create --name c8s-rg --location northeurope

az aks create \
  --resource-group c8s-rg \
  --name c8s-aks \
  --node-count 1 \
  --node-vm-size Standard_DC4as_v5 \
  --os-sku Ubuntu \
  --generate-ssh-keys

Verify the node-pool shape.

Some subscriptions/regions only allow the confidential VM size on a user node pool, not the default system pool. If az aks create rejects the CVM size, create a minimal regular system pool and add the confidential pool separately:

az aks nodepool add \
  --resource-group c8s-rg \
  --cluster-name c8s-aks \
  --name conf \
  --mode User \
  --node-count 1 \
  --node-vm-size Standard_DC4as_v5 \
  --os-sku Ubuntu

With a separate system pool you no longer have a single node — drop --single-node at install time and let the CDS schedule onto the confidential pool (label/taint it so only confidential workloads land there).

2. Point kubectl at the cluster

az aks get-credentials --resource-group c8s-rg --name c8s-aks
kubectl get nodes -o wide

Everything from here runs from your laptop — there's no node to SSH into. When the node reports Ready, you're ready to install c8s.

Next: install c8s

Your cluster is now a managed AKS cluster whose node is a confidential CVM, with kubectl wired up on your laptop. Continue to Install c8s.

Two Azure-specific flags to know up front.

--cvm-mode aks selects the device shape. Attestation on Azure comes from the vTPM at /dev/tpm0, never a native /dev/sev-guest or /dev/tdx-guest device — those are not exposed to an Azure guest. Despite the name the mode means "Azure vTPM" and applies to any Azure confidential VM.

--hardware-platform selects the CPU TEE inside that vTPM report, which wraps either an SNP report (az-snp) or a TD quote (az-tdx). The default sev-snp is right for the DCas_v5 pool above; on a DCes_v5 / ECes_v5 Intel TDX pool, pass tdx. Nothing else differs — there is no TDX node label to apply and no guest device to expose:

c8s install --single-node --cvm-mode=aks --hardware-platform=tdx --operator-keys operator.pub

operator.pub is the allowlist-write credential you generate in the first step of the install guide. Neither install pins a launch measurement on its own. Because the node image here is Azure's, not one you built, read the measurement off the running cluster once with an unpinned c8s verify, then re-run c8s install with --measurements <M> — Obtaining launch measurements covers the procedure. For the full provision-through-verify path on one page, follow Your first confidential cluster.

Validate the host-side install on managed nodes.

c8s's node-as-CVM install runs privileged DaemonSets that touch the node host: nri-image-policy patches the node's containerd config and restarts it, ratls-mesh sets up iptables, and attestation-api mounts /dev/tpm0. This is routine on self-managed nodes; on a managed AKS node pool, confirm these complete and survive node image upgrades / reconciliation before relying on it in production — AKS may reconcile host changes on upgrade.

Why pod-as-CVM is not available on Azure

This is the key limitation to plan around:

Azure's hypervisor does not expose nested virtualization. A pod-as-CVM design launches a new confidential VM inside the node for every pod — that requires nesting, which Azure does not provide. So each AKS confidential node is a single node-level CVM, and all pods on it share that one confidential boundary. Don't use --cvm-mode=pod on Azure.

Concretely, on AKS:

✅ Node-as-CVM works. Each node runs as one confidential CVM; its memory is opaque to the Azure operator. Attestation is at the node level — verify the node's launch state once and every pod on it inherits that verified boundary.
❌ Pod-as-CVM (Kata per-pod VMs) does not work. Launching a VM inside the node VM would be nested virtualization, which the platform does not support.
✅ You still get strong guarantees. Pod identities are issued by the CDS, the image allowlist is enforced at the node, inter-node traffic (once you scale past one node) is RA-TLS-protected, and the CDS issues certificates only to peers whose evidence verifies.

The tradeoff is attestation granularity: on Azure you cannot distinguish two pods on the same node at the attestation level — they are inside the same TEE.

Self-managed and bare-metal hosts

If you need pod-as-CVM (per-pod isolation from the cluster operator), or you're running outside Azure, you need a bare-metal-class confidential host that allows nested VMs. Provisioning that host (and a self-managed Kubernetes on it) is out of scope for this AKS guide; once you have a cluster on it, Install c8s is the same flow — use --cvm-mode=pod for pod-as-CVM, or --cvm-mode=node (--cvm-mode=gke on GKE's native /dev/sev-guest) for node-as-CVM. See pod-as-CVM vs node-as-CVM for the full comparison.