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 and enforcement gaps

• Measurements are not pinned by default. The chart ships cds.measurements and ratlsMesh.measurements empty, which means "accept any attested peer". Both the CDS and ratls-mesh log warnings when their allowlists are empty, and ratls-mesh publishes ratls_mesh_measurement_pinning=0, but the accept-any policy still stands until you set the values. On a node-shaped install (--cvm-mode=bare-metal, gke, aks), c8s install --measurements <LAUNCH_DIGEST> pins the node digest into both. See the threat model.

• Under --cvm-mode=bare-metal the baked image-policy config pins no CDS measurement. That mode leaves nriImagePolicy.enabled false, because the node image bakes its own fail-closed nri-image-policy plugin and the config measured into the image is what the plugin boots with. That config ships cds_measurements: [], so when the plugin pulls the allowlist it accepts any RA-TLS-attested CDS and logs a warning naming the unset field. c8s install --measurements pins the CDS for the chart-deployed components; the baked config is inside the image, so the install does not reach it.

• Mesh peer verification doesn't pin the peer measurement. A mesh peer is accepted if its certificate chains to the mesh CA. Issued leaves do now carry the evidence the CDS (Certificate Distribution Service) verified at issuance, and the RA-TLS (Remote-Attestation TLS) verify policy has a RequireCAEvidence mode that re-checks it — measurement included — on every connection, but no shipped profile enables it.

• A workload's sandbox identity is CA-vouched, not hardware-bound. c8s verify --sandbox-id checks the CRI sandbox ID stamped into a leaf, but that ID is signed in by the mesh CA on the word of an on-node admission inventory; it is not folded into the Trusted Execution Environment (TEE) report. Any process that can bind the node's privileged inventory port — including a privileged node DaemonSet — can vouch for a sandbox it does not run, and a compromised mesh CA can mint any ID. Treat it as CA-vouched identity, not attested identity.

• The allowlist gates each container's digest and command line — not the rest of the pod spec. Floor entries admit an image by digest alone. Workload entries additionally pin each container's command prefix and args remainder against the effective argv, and both enforcement points — nri-image-policy and the CDS at certificate issuance — apply it. Env, mounts, capabilities, and the remaining pod-spec fields are not checked.

• Nothing enforces which images run together. Every running image must be allowlisted, but no gate requires the set that runs in one pod to match a single workload entry. Container-start gates see one container at a time and cannot detect a missing one; the CDS sees the whole reported set but only at issuance, mid-lifecycle, so it checks membership rather than composition. The one decision that does require a whole entry to match is secret release, which lands after every main container is up — but it withholds a secret, it does not stop the wrong set from running.

• Allowlist write authorization is pinned-key, not PKI. Writes are authorized by long-lived operator public keys pinned in cds.operatorKeys. Revocation is coarse — remove the key and re-install, with no CRL/OCSP. Write tokens are bound to body, method, and path with a five-minute server cap, but carry no cluster binding, so clusters pinning the same operator key accept each other's captured tokens within that window — pin distinct keys per cluster. The pinned list itself is host-supplied config that the CDS serving certificate does not commit: c8s cds verify --operator-keys fetches the served set over the attested serving cert and fails closed against your own bundle, but that protects only the verifier that runs it — in-cluster enforcers run none, so run it continuously, not just at bootstrap. The applied allowlist seed is not covered by any attestation. A CA with short-lived operator certificates is the planned replacement. See Authorizing mutations.

• Certificate revocation is not checked. The attestation-api ships with CRL checking off (require_crl=false, and the chart exposes no value to turn it on), and the in-process Go verification path for AMD SEV-SNP performs no revocation check at all. An adversary who blackholes the AMD CRL endpoint gets a revoked AMD attestation key (VCEK) accepted.

• A mutable encrypted volume is not integrity-protected. c8s volume create --mutable builds ext4 over dm-crypt with no dm-verity layer, so a host that flips bits or rolls the device back to an earlier state is not detected. Confidentiality holds; integrity does not. The default immutable volume is verified block by block on every read. See What this defends.

• 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.

• Exempt namespaces bypass injection and image policy. The release namespace, kube-system, kube-public, and kube-node-lease skip webhook injection, and kube-system also skips image policy. Host-namespace pods are exempt from that policy too, so anyone with create-pod RBAC in an exempt namespace opts out with hostNetwork: true — and so does anyone in any namespace if you set hostNamespacePolicy.enabled=false (the deny-host-namespaces validating policy is on by default).

Availability and operations

• The CDS is a singleton. The mesh CA key lives only in CDS process memory, so a restart generates a new CA and invalidates existing leaves — see Mesh CA bootstrap. There is no restart continuity today; replicas stay fixed at one.
• Operator-added allowlist entries don't survive a CDS restart. cds.persistence.enabled is false by default, so the store is an emptyDir and a restart drops back to the install seed — workloads pulling those images are denied roughly one poll interval (5s) later. Set cds.persistence.enabled=true for an RWO PVC, or re-run c8s allowlist add after a restart.

Platform constraints

• 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.

Browser and out-of-cluster verification

• Browser verification is SEV-SNP only. The c8s cds-attest sidecar can serve TDX evidence, but the c8s-verify WASM verifier implements the snp and az-snp paths only; tdx is reserved in the wire protocol and not implemented.
• The WASM verifier enforces fewer checks than the server verifiers. Its bare-snp path omits the VMPL-0 check, debug-policy rejection, minimum-TCB enforcement, VEK validity, and CRL. A browser client would accept a debug-enabled or non-VMPL-0 guest — one whose memory the host can read — if its measurement is allowlisted.
• The over-encrypted channel is not streaming. The sidecar buffers each sealed request and each upstream response into a single tunnel envelope, so chunked transfer from the upstream does not bypass the buffering. Uploads are bounded by the sidecar's request-record cap, and upstream responses over 32 MiB fail rather than stream. Large transfers need application-level range or chunk APIs.

Out of scope for this milestone

• Pod-spec integrity checking beyond the per-container digest and argv policy.
• Active/active CDS high availability.
• Multi-tenant isolation between workloads on the same node, and federated multi-cluster control planes.