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.”
Security analysis always starts by drawing the TCB boundary. A process on bare metal trusts the kernel and firmware. A container on Kubernetes additionally trusts the host kernel (shared with every other container on the node), containerd or CRI-O, the kubelet, CNI, and often the cloud hypervisor beneath the VM — a large TCB with a large shared blast radius. A VM via KubeVirt adds QEMU/KVM and libvirt to the host TCB but gives the workload its own kernel. Kata Containers and OpenShift Sandboxed Containers push the isolation boundary to a micro-VM so a container escape must cross a VM boundary first, though the hypervisor remains in the host TCB. Hardening does not remove the TCB but constrains it: SELinux sVirt isolates QEMU processes, seccomp limits syscall exposure, measured boot and Secure Boot make firmware-to-kernel transitions auditable, and RHCOS on OpenShift shrinks mutable host configuration. The residual risk is structural: you are still trusting whoever operates the layers below your workload.
Confidential computing reframes the problem by shrinking what the workload owner must trust. A TEE — TDX, SEV-SNP, or Arm CCA — encrypts guest memory so the hypervisor and cloud operator fall outside the workload’s confidentiality TCB even if they are compromised. CoCo (Confidential Containers) treats the Kubernetes control plane as explicitly untrusted and uses Kata Containers plus Trustee attestation to release secrets only into verified Confidential VMs. A Confidential Cluster goes further by running every node, including the control plane, inside CVMs so the infrastructure operator is excluded from the cluster TCB entirely. Attestation (TPM, Keylime, Trustee) is how you verify the TCB before trusting it: signed evidence that firmware, kernel, and guest images match expected measurements. Together, these technologies do not eliminate trust — they make the trusted set smaller, explicit, and cryptographically checkable.