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.
Trustee is composed of three services with distinct responsibilities. The Key Broker Service (KBS) is the front door: it speaks the RCAR (Request-Challenge-Attestation-Response) protocol with the Attestation Agent inside the guest TEE, issues cryptographic challenges, receives the resulting hardware evidence (a TDX Quote or SEV-SNP attestation report), and enforces access control over the secret resources it manages. The KBS maps to the RATS Relying Party. The Attestation Service (AS) is the evidence verifier: it receives raw TEE evidence from the KBS, calls the appropriate hardware-specific verifier (Intel DCAP for TDX, AMD’s certificate chain for SEV-SNP, or a third-party service such as Intel Trust Authority), and returns a signed attestation result token indicating whether the evidence is valid and which policy claims it satisfies. The AS maps to the RATS Verifier. The Reference Value Provider Service (RVPS) manages the ground truth: it stores the expected measurement values — the composefs digest of the OS image, the expected firmware version, the approved initrd hash — against which the AS evaluates evidence. An attestation passes only if the TEE’s measured values match what the RVPS records as acceptable.
The guest-side counterpart to Trustee is the Attestation Agent (AA) and Confidential Data Hub (CDH), which run inside the TEE as part of the CoCo guest components. The AA collects TEE-specific evidence and conducts the RCAR handshake with the KBS; the CDH provides in-guest APIs through which workload processes request secrets without ever seeing the KBS communication directly. Secrets released by the KBS — disk encryption keys, registry pull credentials, TLS certificates, API tokens — are delivered into the CDH inside the encrypted TEE memory and never exposed to the host. Trustee also supports a passport mode borrowed from RATS: a first KBS instance acts as a pure verifier and issues a signed attestation token (the passport); a second KBS instance, which may be operated by a different party, accepts that token without re-verifying the raw hardware evidence, enabling decoupled, multi-party secret provisioning workflows. In the broader glossary context, Trustee is the component that gives CoCo its secret delivery capability and is what distinguishes a confidential container from a merely isolated one: isolation is provided by TDX or SEV-SNP; trust, verified and acted upon, is provided by Trustee.