Threat model

C8s treats a confidential Kubernetes node as one trusted execution environment (TEE). Pods share that hardware boundary; use separate confidential nodes for mutually distrusting tenants. The node kernel, kubelet, container runtime, and privileged node services form part of the trusted computing base. These include the node inventory service, which reports admitted containers. The Certificate Distribution Service (CDS) holds the mesh CA and secret state inside a separate confidential VM.

The host and hypervisor are adversarial. They can deny service, control external networking and storage, and observe traffic and exposed metadata. Protection of guest memory assumes functioning TEE hardware, firmware, and evidence verification for the deployed platform. Repository checks alone do not establish hardware attack resistance or provider guarantees.

What C8s checks

The image-policy plugin uses the container runtime's Node Resource Interface (NRI) to enforce admission and runs the node inventory service. A sandbox ID identifies the runtime's instance of a pod.

These restrictions cover pod containers outside the measured policy's exempt namespaces, kube-system and c8s-system; the runtime-created pod sandbox is also exempt. Covered containers must run as non-root, prevent privilege escalation (no_new_privs), use private process namespaces, and hold only permitted capabilities. The runtime also checks their working directories. It refuses checkpoint restore and container creation with a terminal or open standard input in every namespace. The default locked build mode also refuses exec, which starts an extra process in an existing container.

Host-privileged platform launches require admission by the measured base policy: a static pod from a node-local manifest must match that policy, while other pods need rules constraining their image, command, arguments, environment, and mounts. GKE and AKS use chart-managed NRI; enforcement there remains under the cluster administrator's control. See node trust boundary.

Ordinary mesh connections authenticate sandbox certificates without rechecking hardware evidence or restricting destination workload names. Private mesh credentials belong to injected platform containers; the webhook rejects application mounts of that volume. Application authorization remains a separate responsibility.

Pin the measurement

Pin the expected CDS image and exact launch configuration, independently of the node and router identities you expect. CDS verifies its configuration bytes against its own launch evidence before serving. This measured configuration binds operator public keys, workload policy, node policy inputs, inventory address ranges, and certificate naming rules. Missing operator keys fail startup; an empty current node policy refuses issuance. See the trust root.

The configuration supplies node policy for a single-replica CDS without high availability (HA). In HA mode, an operator-signed Genesis command initializes the replicated cluster and selects its starting node set, using the configured policy as its default. Later signed commands can change that set. A CDS identity pin therefore does not freeze the served node policy. c8s cds verify --served-policy-file <FILE> compares it with the file's independently intended current node policy. See obtain launch measurements and verify a deployment.

Operator authorization keys confer policy authority. Their holders can authorize workloads, secrets, routes, and direct TCP exits: permitted connections to specified IP ranges and ports that bypass mesh capture. Kubernetes controllers orchestrate resources; CDS makes certificate and secret-release decisions.

Remaining risks

Allowlist entries constrain the launch fields they specify. A signed egress entry additionally requires pinned arguments and mounts, but permits env: any. Its exits open only when observed workload containers uniquely satisfy every declared main-container policy without foreign additions. For example, an entry requiring an API image and a different worker image needs launch evidence satisfying both policies. If no other entry admits that set, its exits open; adding a workload container outside that entry is then refused. That match checks container evidence, not init/main lifecycle identity or every pod-spec field. Changing or removing exits requires pod recreation. See the image allowlist.

Network rules have explicit exceptions for DNS, local and reply/control traffic, health checks, platform roles, and signed exits. The bare-metal image permits uncaptured TCP to kube-state-metrics at 10.53.0.11:8080, exposing cluster object metadata. Direct exits supply neither payload encryption nor inspection, and rule verification occurs at admission and identity assertion rather than continuously.

A router address backend sends requests over TLS to a configured host and port. It authenticates the server name and certificate chain under the route's CA anchors and offers the router credential as client identity. It establishes neither workload identity nor confidential execution; mesh-CA chains are rejected. See certificate and traffic flow.

Ordinary Kubernetes Secrets, including image-pull credentials, remain exposed to control-plane access and must not hold TEE-only application secrets. HA retains volatile CA and secret state across surviving replicas, but service stops when its leader-confirmed lease ceases to hold; losing all replica memory loses that state. See limitations.