Installing c8s

This guide installs c8s onto an existing Kubernetes cluster that is already running on confidential hardware. If you do not have a cluster yet, start with Provisioning a confidential cluster on Azure, then come back here.

For the exhaustive flag list of every subcommand, see the CLI Reference.

Prerequisites

• A Kubernetes cluster (k8s or RKE2) whose nodes run on confidential hardware — AMD SEV-SNP (Genoa / Milan / Turin) or Intel TDX. For the confidential pod runtime you additionally need a bare-metal-class host that allows nested VMs — see pod-as-CVM vs node-as-CVM.
• kubectl configured for the target cluster.
• helm on PATH (the chart is embedded in the binary and installed via Helm).
• crane on PATH — needed for the default --resolve-digests=true, which pins each component image to its registry digest. A private registry needs a local login first (see below).
• The c8s CLI, built with make install (see below).

crane auth login ghcr.io -u <user> --password-stdin

Quickstart: a single-node cluster

For a single-node cluster, pass --single-node. This clears the dedicated-CDS node selector and taint toleration so every node is CDS-eligible — there is no separate role=cds node to label or schedule. (It's about node count, not the number of pod CVMs: a multi-node cluster running a single Kata pod still wants a dedicated CDS node, so leave it off there.)

openssl ecparam -name prime256v1 -genkey -noout -out operator.key
openssl ec -in operator.key -pubout -out operator.pub

c8s install --single-node --operator-keys operator.pub

c8s install --single-node --kata --operator-keys operator.pub

c8s install --single-node --cvm-mode aks --operator-keys operator.pub

c8s install --single-node --kata --hardware-platform tdx --operator-keys operator.pub

kubectl get pods -n c8s-system

kubectl get pods -A -w

The flags that change the install shape

A handful of flags determine the trust model and topology. The rest tune webhook-injected certificate defaults — see the CLI Reference.

kubectl label node <NODE> confidential.ai/tdx=true

Run a confidential workload

Once installed, mark a workload for confidential treatment with the confidential.ai/cw annotation. Under pod-as-CVM (--kata) the webhook injects the kata-qemu-snp RuntimeClass and a get-cert init/sidecar that fetches a TEE-bound certificate from the CDS:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-inference
spec:
  template:
    metadata:
      annotations:
        confidential.ai/cw: my-inference   # the workload identity (NOT a boolean)
    spec:
      containers:
        - name: server
          image: ghcr.io/example/inference@sha256:...   # must be on the allowlist

Make sure the image digest is on the allowlist, or policy-monitor will refuse to start the container.

Verify the install

A few quick checks confirm everything came up.

Components are healthy — CDS, the operator, and (under pod-as-CVM) kata-deploy should be Running:

kubectl get pods -n c8s-system

The admission webhook is wired up — the operator patches its caBundle once at startup, so it should be non-empty:

kubectl get mutatingwebhookconfiguration | grep c8s
# caBundle populated? (any non-zero count means it's patched)
# the config is named <release>-pod-injector (release defaults to c8s):
kubectl get mutatingwebhookconfiguration c8s-pod-injector \
  -o jsonpath='{.webhooks[*].clientConfig.caBundle}' | wc -c

A workload got its confidential identity — inspect a pod you annotated confidential.ai/cw. Under pod-as-CVM it should run under the kata-qemu-snp RuntimeClass and carry the injected get-cert init container:

# confidential RuntimeClass (pod-as-CVM) — describe shows it directly:
kubectl describe pod <pod> | grep "Runtime Class"
#   Runtime Class Name:  kata-qemu-snp

# the webhook-injected get-cert init container is present:
kubectl get pod <pod> -o jsonpath='{range .spec.initContainers[*]}{.name}{"\n"}{end}'
#   c8s-cert

End-to-end confidentiality — verify it from outside the cluster with c8s-verify.

Uninstalling

c8s uninstall reverses the install — same --namespace / --release defaults as c8s install:

c8s uninstall

It runs helm uninstall to remove the release (operator, CDS, attestation-api, ratls-mesh, tls-lb, webhook configuration, RuntimeClasses, enforcement policy), and for a --kata install it then sweeps the host-side kata artifacts off every node — /opt/kata, the containerd runtime drop-in, the multi-GB kata-guest-base image, the RKE2 prep template, and the kata-runtime node labels — via a short-lived privileged DaemonSet. The sweep is read from the release's computed values before deletion, so install-time -f overrides are honored, and it's skipped automatically for a non-kata install.

To remove kata leftovers from a cluster whose release is already gone (e.g. a previous bare helm uninstall), run just the sweep:

c8s uninstall --host-sweep-only

See the CLI Reference for every flag.