Provisioning a confidential cluster on Azure (AKS)

Prepare an AKS confidential node pool and check the prerequisites for installing c8s with an external measured CDS.

Prepare Azure Kubernetes Service (AKS) confidential nodes for c8s, then continue to Install c8s to launch the external Certificate Distribution Service (CDS) and install the cluster components. Each node confidential VM (CVM) is a Node-as-CVM trust domain. Azure's managed control plane stays outside that boundary; see trust boundaries.

Validate the Azure deployment shape.

The c8s installer supports aks with AMD SEV-SNP or Intel TDX. This guide's Azure CLI templates have not been validated against a live AKS deployment. Confirm the CLI version, subscription quota, region, SKU, system-pool eligibility, node image, and network configuration with your provider before provisioning. A VM SKU listing alone does not establish AKS support or successful attestation.

Prerequisites

  • An Azure subscription, the Azure CLI installed and authenticated, and kubectl on your workstation.
  • Azure authorization to provision the selected resource group, cluster, node pools, and networking. Before preparing CDS, obtain a Kubernetes identity authorized to install the chart's cluster-scoped resources and create or update component namespaces, including their labels permitting privileged pods.
  • An AKS-supported Kubernetes version 1.30 or newer and a provider-validated confidential pool configuration, including the system pool. This procedure requires confidential nodes for both c8s system components and tenant workloads.
  • A network configuration in which every Kubernetes node publishes spec.podCIDR or spec.podCIDRs. Prepare the node inventory subnets, pod ranges, and service ranges; node inventory subnets are the CIDRs containing the admitted nodes' inventory endpoint addresses that CDS contacts on TCP 1019. These CIDRs must exclude pod and service ranges. This guide does not establish an AKS network mode that satisfies these requirements.
  • Independently approved complete JSON policies for the nodes CDS may admit and the nodes hosting the router. Prepare these before CDS configuration; see Node CVMs on stock Azure images.
  • The approved CDS build bundle and a separate VM launch mechanism supporting its measured configuration disk, as required by Install c8s. Arrange workstation and cluster access to CDS on its client port, normally TCP 8443, and CDS access to admitted nodes' inventory on TCP 1019.

Confidential VM sizes

Have your Azure subscription or platform administrator supply a deployment record validated against Azure's supported AKS configurations. The record must contain the Azure CLI version, subscription and quota, <REGION>, <KUBERNETES_VERSION>, <CONFIDENTIAL_NODE_SKU>, <NODE_COUNT>, <NODE_OS_SKU>, node image, and system/user pool roles. Include the exact network options for az aks create, node inventory CIDRs, pod ranges, and service ranges. Validate the node's Trusted Execution Environment (TEE) as AMD SEV-SNP or Intel TDX, and confirm that its image exposes the Azure vTPM evidence path required by c8s.

Do not infer a supported pool shape from a standalone Azure CVM offering. If your provider cannot supply a confidential system pool for this procedure, stop and resolve the deployment shape. A regular system pool with a confidential user pool needs separately verified placement for all c8s components, the router, and workloads; adding a confidential pool alone does not establish that placement.

Use the verified TEE for the install flags in Next: install c8s.

Step by step

Record the provider inputs and create the cluster

Record the CLI version alongside your approved provider configuration:

az version

Adapt this template using that configuration. Replace the placeholders and add the approved network options before running az aks create; the template does not select a network mode.

az group create --name c8s-rg --location '<REGION>'

az aks create \
  --resource-group c8s-rg \
  --name c8s-aks \
  --kubernetes-version '<KUBERNETES_VERSION>' \
  --node-count '<NODE_COUNT>' \
  --node-vm-size '<CONFIDENTIAL_NODE_SKU>' \
  --os-sku '<NODE_OS_SKU>' \
  --generate-ssh-keys

<KUBERNETES_VERSION> is the provider-supported version selected above. Confirm the resulting system pool and any additional pools use the approved confidential configuration. Treat a provider rejection as an unmet provisioning prerequisite.

Connect kubectl and check every node's pod ranges

az aks get-credentials --resource-group c8s-rg --name c8s-aks
kubectl get nodes -o wide
kubectl get nodes \
  -o custom-columns='NAME:.metadata.name,POD_CIDR:.spec.podCIDR,POD_CIDRS:.spec.podCIDRs'

Require all intended nodes to be Ready and every row to contain a pod CIDR in at least one of the two pod-range columns. If any node has neither field, resolve the cluster's pod-range publication before preparing CDS. Explicit --pod-cidr values in CDS configuration do not bypass the later installer check: it rejects missing node pod ranges even if component seed generation succeeds.

Node readiness establishes Kubernetes health. The approved node policies and subsequent attestation checks establish the identities c8s trusts.

Next: install c8s

Follow Install c8s with --cvm-mode=aks and --hardware-platform=sev-snp or --hardware-platform=tdx matching the verified node configuration. The aks mode configures the /dev/tpm0 evidence path and the corresponding Azure report type. The external CDS selects its own TEE separately.

Keep the install sequence intact:

  1. Generate the component seed with the exact release, image tag, values files, and component options you intend to install, including router TLS and ingress settings.
  2. Generate the measured CDS configuration with that seed, the approved node policy, operator public keys, and cluster ranges. Launch CDS independently using its build bundle and configuration disk.
  3. Verify CDS with its own image/configuration pin and the independently approved current node image policy: the JSON policy describing the launch identities CDS may admit. Use that policy as <NODE_POLICY_JSON> in Launch and verify the external CDS. Require verification exit code 0, then fetch and retain the mesh CA through the pinned CDS connection.
  4. Install with the same seed-generation settings, adding --cds-address '<CDS_HOST>:<PORT>' --cds-pin cds-bootstrap/cds-pin.json. The installer requires every rendered component entry to equal its entry in the seed bound into that CDS pin. Changed release or component settings require a matching seed and measured CDS configuration before installation.

<CDS_HOST>:<PORT> names the independently launched CDS endpoint. The cluster components run in c8s-system by default; the router runs in c8s-router. Verify the reachable router with its approved node policy and retained mesh CA using Verify a deployment. The router policy and CDS pin identify different targets. An observed node report alone is trust-on-first-use, not an independently approved policy; use Obtain launch measurements to prepare those inputs.

Deployment model on AKS

Workload pods run inside their node CVM and share its trust boundary. The webhook injects the per-pod c8s-mesh endpoint into every covered pod. The node's NRI plugin installs packet rules inside the pod; applications serve ordinary TCP/HTTP and mesh credentials remain private to platform containers.

Validate the chart-managed nri-image-policy installation, containerd integration and restart, attestation-api access to /dev/tpm0, pod packet rules, and component placement on the chosen AKS image. Repeat these checks for provider image upgrades and reconciliation before relying on that configuration. Managed-node compatibility and upgrade persistence remain unverified by this guide.