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). It is required, like --cvm-mode: pass sev-snp for the DCas_v5 pool above, tdx on a DCes_v5 / ECes_v5 Intel TDX pool. 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.

Deployment model on AKS

Use --cvm-mode=aks for an AKS confidential node. Workload pods run as ordinary containers inside that node CVM and share its trust boundary. Azure attestation evidence comes from /dev/tpm0; set --hardware-platform=sev-snp or tdx to match the node pool. For self-managed confidential nodes, use --cvm-mode=bare-metal; for GKE confidential nodes, use --cvm-mode=gke. See trust boundaries.