Limitations

c8s is built around a strong threat model, but not every gap is closed yet. This page is the honest list of what the current milestone does not do, so you can plan around it. Several items are deliberate non-goals for now; others are tracked work.

Trust & enforcement gaps

• Measurements are not pinned by default. The chart ships with cds.measurements and ratlsMesh.measurements empty, which means "accept any attested peer". This is fine for demos but must be set for production — see the threat model.
• Mesh peer verification doesn't pin the peer measurement. A mesh peer is accepted if its certificate chains to the mesh CA; the peer's launch measurement is not additionally checked on the handshake.
• Leaf certificates don't embed the verified TEE measurement. The measurement is checked at issuance time, but it is not carried inside the leaf for downstream re-verification.
• The image allowlist gates the digest only. nri-image-policy / policy-monitor enforce the container-image digest — not args, env, mounts, capabilities, or the rest of the pod spec.
• Allowlist write authorization is pinned-key, not PKI. Writes are authorized by long-lived operator public keys pinned in cds.operatorKeys. Revocation is coarse — removing the key and re-installing, with no CRL/OCSP. Write tokens are bound to body, method, and path but carry no cluster binding, so clusters pinning the same operator key accept each other's captured tokens within the five-minute validity cap — pin distinct keys per cluster. And the pinned list itself is host-supplied config outside the CDS launch measurement: c8s cds verify reports the pinned-key fingerprints so a swap is visible, but not measured. A CA with short-lived operator certificates is the planned replacement. See Authorizing mutations.
• No per-workload peer allowlists in the mesh. Any attested mesh peer can talk to any other; there is no per-workload restriction on who may connect to whom.
• No SPIFFE-style URI SAN identities. Workload identity is carried by the CDS-issued cert's SANs/CN, not a SPIFFE URI scheme.

Availability & operations

• The CDS is a singleton by default. The mesh CA key lives only in CDS process memory, so a restart generates a new CA and invalidates existing leaves. HA via attested CA handoff is opt-in (cds.handoff.enabled=true) — see CDS handoff.
• Flipping kata.enabled on a live cluster is disruptive. Node-as-CVM and pod-as-CVM move components between host and guest; switching in place is not a seamless toggle.
• A small post-start kill window exists under Kata. policy-monitor SIGKILLs a non-allowlisted container's init PID, but the init fork happens a few milliseconds before the kill lands.

Platform constraints

• Pod-as-CVM is unavailable on Azure. Azure does not expose nested virtualization, so AKS runs node-as-CVM only — all pods on a node share one confidential boundary. See Provisioning on Azure.
• One CPU TEE per cluster for confidential pods. The per-pod runtime (--kata) supports AMD SEV-SNP and Intel TDX, but an install picks exactly one via --hardware-platform (rendering kata-qemu-snp or kata-qemu-tdx), and the webhook promotes every confidential pod to that one class — mixed SNP + TDX clusters are not supported. On a host with neither TEE you can still run kata-qemu (isolation without confidentiality).
• Browser verification is SEV-SNP only. The c8s-verify WASM verifier ships AMD ARK/ASK roots and verifies SEV-SNP evidence; TDX is reserved in the wire protocol but not yet implemented.
• Confidential GPU ships, with gaps. Kata clusters run GPU pods as confidential VMs with the NVIDIA GPU passed through over VFIO (Blackwell-class, CC mode) — request an nvidia.com/* resource and the webhook injects the confidential GPU RuntimeClass. Current gaps: the GPU's own attestation (SPDM) is not yet surfaced to the relying party (a non-CC GPU fails closed at guest boot, but there is no positive GPU evidence in the attestation result); the GPU guest boots kata's GPU kernel (measured, but not our hardened configuration); and on SEV-SNP each GPU pod is pinned to a single vCPU to keep the launch measurement stable. Host GPU provisioning (vfio-pci binding, GPU CC mode, BAR resize) is assumed done before install; the NVIDIA GPU Operator is not used on this path.
• Don't run an external service mesh alongside c8s. c8s installs its own pod-to-pod RA-TLS mesh — transparent iptables redirection plus attestation-gated mTLS. A second service mesh (Istio, Linkerd, or any sidecar / mTLS plumbing) double-intercepts the same traffic, collides with the RA-TLS handshake, and injects un-attested proxies into the confidential path — breaking the trust model rather than adding to it. Run c8s without one; it already provides the mTLS layer, rooted in hardware attestation.

Out of scope for this milestone

• Pod-spec integrity checking beyond the image-digest allowlist.
• Attestation-gated release of application secrets (the CDS key-brokering path).
• Multi-tenant isolation between workloads on the same cluster beyond the CVM boundary, and federated multi-cluster control planes.

For the verification client's roadmap (binding the LB leaf into attestation, removing the pinned mesh CA PEM), see consumer verification.