Operations and FAQ

Use separate workers. Pods on a worker share a guest kernel, container runtime and hardware Trusted Execution Environment (TEE).

Namespaces and container restrictions do not create a hardware boundary between those pods. Stronger tenant isolation is on the roadmap.

CDS runs in independent confidential VMs, outside Kubernetes. Place replicas on separate physical failure domains when availability requires it; they can share a host with workers or run elsewhere with the required connectivity.

Three voting replicas tolerate one loss while a connected majority retains its serving lease. Follow Start policy enforcement for direct peer DNS, ports and TLS-passthrough load balancing.

A verifier rejects an image, launch configuration or route outside its approved pins. On TDX, TEErminator can also require every policy measured since boot, and the router leaf's issuing policy, to be approved.

Protect and distribute those pins independently of the cluster operator. Accepting arbitrary operator signatures delegates future policy approval to that signer.

The measured worker enforces its admitted launch policy. The router checks backend mesh identity against the signed route and checks the backend's workload policy against its own policy, including supported policy-history transitions. A route pin and a router-image pin describe that trusted routing path; they are not a direct attestation of the application backend.

Follow Verify a connection for the client data path. A later pin change cannot recover plaintext already exposed by a compromise.

The measured image uses a restricted kernel, immutable root and a small set of runtime services. These reduce attack surface; they do not prove that the guest has no exploitable CVEs.

Patch the kernel, runtime and applications, review the resulting image measurements, and roll the approved image. Attestation identifies measured software, not its vulnerability status or continuous runtime integrity.

A container escape reaching the guest kernel or guest root can compromise that worker's pods, keys and plaintext. Other workers and CDS have separate TEE boundaries; exposure also depends on what credentials and permissions the compromised workload holds.

Host or hypervisor root remains outside the guest TEE. The measured worker provides no general guest SSH or interactive debug interface.

Yes. The built-in router supports CDS-issued certificates and ACME certificates. The in-guest ACME issuer generates the private key inside the worker and keeps it in memory-backed storage; the public certificate authority receives the certificate request, not that key.

DNS/challenge reachability and certificate renewal remain operational requirements. The first-workload example selects a CDS-issued certificate; verification still pins the worker and routing policy when using a publicly trusted certificate.

When replacing workloads:

• Approve new image digests and launch constraints.
• Review and distribute new client pins before routing private requests to the new identity.
• Keep both reviewed identities or route digests accepted during the overlap, then remove the outgoing ones.
• Retain every canonical policy a running TDX worker has measured since boot for policy-history verification.

Drain and replace workers one at a time with enough remaining capacity for your workloads. Stop or fence the old VM before reusing its primary IPv4; that address determines the worker's node name. Re-run the readiness and connection checks after replacement.

CDS, workers and the external Kubernetes control plane have separate lifecycles. A worker's kernel, kubelet and container runtime are baked into its measured image; changing them requires image replacement and approved measurements.

CDS image updates have their own admission pins and replicated-state format compatibility requirements. Check compatibility for the selected releases.

For CDS, replace one replica only after the leader reports roll_safe=true, and wait for it to rejoin and restore that gate before the next replacement.

Application metrics and exporters can run as admitted workloads with their required network access. Kubernetes objects and events remain useful for control-plane diagnostics.

Agents requiring host namespaces, unrestricted devices, privileged containers or elevated capabilities cannot be assumed to work unchanged. Integrate required guest-level instrumentation into a reviewed measured image and its policy.

Treat every exported metric as data leaving the TEE; avoid labels or payloads containing private inputs.

The measured worker disables kubelet log and debugging handlers, including kubectl logs, exec, attach and port-forward. Applications can produce logs, but exporting them requires an application-configured destination and approved policy. Keep private data out of exported logs.

Use pod status and events for platform diagnosis; stdout alone does not provide an operator retrieval path.

GPU workers check every enumerated GPU's NVIDIA Confidential Computing (CC) mode and obtain nonce-bound attestation verdicts before starting the runtime. A failed check prevents workload startup and powers off the worker.

Pin the reviewed GPU worker image containing those checks.

These are guest boot checks. The default client evidence does not identify the physical GPU that processed an individual request. If you need a different GPU verification or monitoring flow, build and approve a custom measured image and define the corresponding client evidence requirements. CPU launch attestation alone does not provide that request-to-device proof.

External key-management integration for worker workloads through CDS plugins is coming soon. The worker journey currently uses CDS-managed secrets.

Keep secrets out of ordinary Kubernetes Secret objects when they must remain hidden from the control plane.

Yes, subject to supported confidential hardware, measured launch and attestation interfaces, routable addresses and the required network paths.

• Workers need access to CDS, the external API server, peer workers, registries and endorsement services.
• CDS replicas need direct peer connectivity and a majority within serving-lease timing.
• WAN failures and latency affect availability.

Validate the chosen substrate; this does not establish support for every provider's confidential VM product.

Disable Istio sidecar injection for c8s workloads. The c8s mesh owns application TCP capture and workload authentication; stacking another transparent sidecar changes that path.

An Istio deployment elsewhere in the cluster is a separate integration question.

This deployment places the hardware confidentiality boundary around a worker. Its pods share that worker's guest kernel. Kata can put a separate guest-kernel boundary around a pod sandbox; its confidentiality guarantees depend on the selected runtime and hardware configuration.

Compare the required isolation boundary and operational cost for your workloads. No comparative performance benchmark is established here.

Replicated state and snapshots are volatile. Simultaneous loss of every CDS replica loses the CA private key, stored secrets, volume keys and policy state. Replication preserves availability through sequential replacements; it is not a durable backup.

The current release has no customer-key-encrypted full-CDS backup and restore interface.

Existing connections or credentials can remain usable within their own lifetime, but new issuance and secret release cannot rely on the lost state.

To recover:

1. Reinitialize CDS with a new CA, preserving the highest prior decree version as the recovery floor.
2. Republish approved policies and restore secrets from retained source material.
3. Update worker and client trust inputs for the new cluster identity.

Encrypted data whose only decryption key lived in CDS is unrecoverable without separate retained key material; individual volume-key escrow is not a CDS backup.