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 Platform Module (TPM) is a tamper-resistant security chip — implemented in hardware (dTPM), firmware (fTPM), or software — that acts as a hardware-anchored root of trust for a system. It provides a secure enclave for generating and storing cryptographic keys, performing cryptographic operations, and recording integrity measurements of the boot process.
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.
Intel Trust Domain Extensions (TDX) is a confidential computing technology built into Intel CPUs that allows entire virtual machines — called Trust Domains (TDs) — to run with hardware-enforced isolation from the host hypervisor, VMM, and any other software on the platform, including privileged system software with administrative access. Unlike SGX, which protects small application-level enclaves, TDX operates at the VM level, making it suitable for lifting existing workloads into a confidential environment without significant code changes.
The Trusted Computing Base (TCB) is everything you must trust for your security guarantees to hold: CPU and firmware, the host kernel, the hypervisor, the container runtime, the kubelet, identity and secrets infrastructure, and any management plane that can change workload configuration. If any component in the TCB is buggy, misconfigured, or controlled by an adversary, the whole security argument fails — regardless of how well the application itself is written. The classic design principle is TCB minimisation: keep this set as small as possible, because every added component is another place where a flaw can void your policy. “Trusted” here does not mean “trustworthy in practice”; it means “assumed correct by the security model.”
SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF graduated specification that defines a standard for workload identity: a universal answer to the question “how does a service prove who it is to another service, without a human provisioning a secret?” The core primitives are simple. A SPIFFE ID is a URI of the form spiffe://trust-domain/path that unambiguously names a workload within a trust domain — for example spiffe://prod.example.com/payments/api. A SVID (SPIFFE Verifiable Identity Document) is a cryptographically signed document asserting that SPIFFE ID, in one of two forms: an X.509-SVID, which is a standard X.509 certificate with the SPIFFE ID encoded in the Subject Alternative Name field (used for mTLS), or a JWT-SVID, which is a short-lived JWT bearing the SPIFFE ID as the sub claim (used for service-to-service authentication where TLS termination is handled elsewhere). A trust bundle is the set of CA certificates for a trust domain that relying parties use to validate SVIDs — analogous to a root CA store, but scoped to a SPIFFE trust domain. The Workload API is the local gRPC API through which a workload retrieves its SVID and the trust bundles of domains it needs to communicate with, with automatic rotation before expiry.
SLSA (Supply-chain Levels for Software Artifacts), pronounced “salsa”, is a security framework published by OpenSSF (originally proposed by Google in 2021, version 1.0 released April 2023) that defines progressively stronger requirements for build integrity and provenance — the verifiable record of where a software artifact came from, what source it was built from, how it was built, and what the build environment looked like. The motivating threat is supply chain attacks like SolarWinds (malicious code injected into the build system) and XZ Utils (malicious code injected into the source repository): in both cases the artifact that reached users was not what the source code claimed, and consumers had no way to verify the discrepancy. SLSA’s answer is a provenance attestation: a signed, machine-readable document produced by the build platform that records the source repository and commit, the build instructions, the builder’s identity, the build environment’s properties, and the digest of the resulting artifact. Signed provenance is the basis on which consumers can make automated trust decisions rather than relying on reputation or manual inspection.
SEV-SNP is AMD’s third-generation confidential computing technology for EPYC processors, and the generation in production use across major cloud providers (AWS, Google Cloud) and Linux distributions today. It builds on two predecessors: SEV (2016), which encrypted each VM’s memory with a per-VM AES key managed by the AMD Secure Processor, and SEV-ES (2017), which additionally encrypted CPU register state on VM exit to prevent the hypervisor from reading guest execution state. SEV-SNP’s defining addition is memory integrity: using Secure Nested Paging, the firmware enforces that if a guest can read an encrypted memory location, the value returned must be exactly what the guest last wrote there — closing the replay, remap, and memory aliasing attacks that made earlier generations insufficient for a fully untrusted hypervisor threat model.
Measured Boot is a boot process architecture in which each component in the boot chain — firmware, bootloader, kernel, initrd, kernel command line — is cryptographically hashed and that hash is recorded into a TPM Platform Configuration Register (PCR) before the component executes. The critical distinction from Secure Boot is in what each mechanism provides: Secure Boot is an enforcement mechanism that prevents unauthorised components from running at all; Measured Boot is a recording mechanism that creates a tamper-evident log of exactly what did run, without necessarily preventing anything. The two are complementary and typically deployed together — Secure Boot enforces a policy at boot time, Measured Boot produces the evidence that the policy was enforced as claimed. A system can have Measured Boot without Secure Boot (it records everything that ran, even unsigned components), but Secure Boot without Measured Boot provides enforcement with no attestable evidence of what was enforced.
Keylime is a CNCF project, originating at MIT Lincoln Laboratory, that turns the raw cryptographic primitives of the TPM into an operable remote attestation system for fleets of Linux machines. Its mission is narrow but important: given that a TPM can produce a signed quote over PCR values, and that IMA can accumulate a runtime measurement log into PCR 10, Keylime provides the infrastructure to continuously collect those quotes from many machines, verify them against policy, react to failures, and gate secret delivery on attestation success — without requiring operators to understand TPM protocols directly.
IMA (Integrity Measurement Architecture) is a Linux kernel subsystem, merged in kernel 2.6.30, that hooks into the kernel’s file access paths — execve(), mmap(), open() — and computes a cryptographic hash of each file’s contents before it is accessed, according to a configurable policy. It is the runtime half of the Linux integrity story: where TPM PCR measurements and Secure Boot cover what was loaded during the boot sequence, IMA covers what happens after the OS is running, hashing executables, libraries, kernel modules, firmware, and configuration files as they are opened, creating a continuously updated record of everything the system has actually used.
A Confidential GPU is a GPU whose memory, computation state, and data transfers are hardware-encrypted and isolated from the host system — extending the Trusted Execution Environment (TEE) boundary that technologies like TDX and SEV-SNP provide at the CPU level to encompass the GPU accelerator as well. The primary implementation today is NVIDIA Confidential Computing on the Hopper architecture (H100 and later), which encrypts all data resident in GPU High Bandwidth Memory (HBM) using per-context keys managed by the GPU’s on-die security processor. This means that model weights, training data, activations, and intermediate computations are cryptographically protected throughout GPU processing — a host administrator, hypervisor, or co-tenant with DMA access to the PCIe bus sees only ciphertext. The GPU also participates in a dedicated attestation flow: the NVIDIA Remote Attestation Service (NRAS) produces signed evidence that a specific GPU is genuine NVIDIA hardware running in Confidential Computing mode with unmodified firmware, analogous to how Intel DCAP or AMD KDS attest CPU TEEs. This GPU attestation is verified alongside CPU attestation before secrets (model decryption keys, dataset credentials) are released to the combined CPU+GPU TEE. The technology requires no application code changes — existing TensorFlow, PyTorch, and CUDA workloads run unmodified inside the confidential boundary. The primary threat model is the same as CPU-level confidential computing (protecting data-in-use from the infrastructure operator) but applied to the specific risk of AI workloads: model intellectual property theft, training data exfiltration, and inference input/output interception during GPU computation.
Confidential Containers (CoCo) is a CNCF sandbox project that lifts hardware confidential computing — TDX, SEV-SNP, Intel SGX, IBM Secure Execution — up to the Kubernetes pod level, providing a unified software layer that abstracts away the underlying TEE technology. Its defining trust model is unusually strict: the Kubernetes control plane, the kubelet, the container runtime, and the cloud operator are all treated as explicitly untrusted. Only the hardware itself and the workload owner’s own supply chain are in scope for trust.
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.
