Trustee is the server-side attestation infrastructure for the CoCo (Confidential Containers) project, previously known as CoCo-KBS. It implements the relying-party and verifier roles from the IETF RATS (Remote ATtestation procedureS) architecture: it receives hardware attestation evidence from workloads running inside TEEs, verifies that evidence against known-good reference values, evaluates it against policy, and — if the workload passes — releases the secrets it needs to operate. Trustee runs outside the TEE in a separately trusted environment (a dedicated server, a different confidential VM, or a Kubernetes operator deployment) and is by design not accessible to the untrusted host or hypervisor.
A Trusted Execution Environment (TEE) is a hardware-enforced isolated execution context whose confidentiality and integrity are protected by the CPU itself, rather than by software policy. The defining property of a TEE is that its guarantees hold against an adversary with full control of the software stack outside it — the hypervisor, the host operating system, the BIOS firmware, and even a user with physical access to the machine — because the enforcement is implemented in silicon and cannot be overridden by software. Code and data inside a TEE are encrypted in DRAM using a key held within the CPU’s memory controller or on-die security processor, CPU register state is isolated from the host at context switch boundaries, and memory integrity protection prevents the host from replaying, remapping, or aliasing TEE memory pages. The threat model TEEs are designed against is therefore the infrastructure provider: a cloud operator, a data centre staff member, or a co-tenant who controls the hypervisor layer — the party that traditional virtualisation, namespaces, and access control cannot protect against because they depend on a trusted host kernel.
A Confidential VM (CVM) is a virtual machine in which the guest’s memory contents, CPU register state, and execution flow are hardware-encrypted and isolated from everything outside it: the hypervisor, the host operating system, the cloud operator, other tenants, and anyone with physical access to the machine. The isolation is enforced not by software policy but by the CPU itself, using TEE technology — Intel TDX, AMD SEV-SNP, or Arm CCA — so that no amount of privilege on the host side grants access to the guest’s private state. A CVM is the VM-granularity equivalent of what SGX enclaves provide at the process level: the key difference is that a CVM requires no application changes, making it the practical path for lifting existing workloads into a confidential computing environment.
A Confidential Cluster is a Kubernetes cluster designed so that the cloud or infrastructure operator — including hypervisor administrators, datacenter staff, and anyone who can access the underlying hardware — is entirely outside the trusted computing base. It achieves this by running every Kubernetes node, including control plane nodes, as a Confidential VM, and by extending the confidential boundary to cover not just individual workloads but the cluster’s network traffic, persistent storage, and control plane state. The goal is that a workload owner can cryptographically verify the entire cluster before trusting it, and that no privileged party outside the cluster’s own CVMs can read or tamper with workload data, cluster secrets, or etcd contents.
