<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Coco on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/coco/</link><description>Recent content in Coco on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/coco/index.xml" rel="self" type="application/rss+xml"/><item><title>Peer Pods</title><link>https://lesitedefrancois.be/en/security/peer-pods/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/peer-pods/</guid><description>&lt;p&gt;&lt;strong&gt;Peer Pods&lt;/strong&gt; is the deployment model for &lt;strong&gt;CoCo (Confidential Containers)&lt;/strong&gt; designed for public cloud environments where the Kubernetes worker nodes are standard VMs — not bare metal — and therefore cannot host a nested confidential VM for each pod. The fundamental constraint it solves is physical: confidential computing hardware (&lt;strong&gt;TDX&lt;/strong&gt;, &lt;strong&gt;SEV-SNP&lt;/strong&gt;) does not support nested virtualisation, meaning a confidential guest cannot be launched inside another VM. In the conventional CoCo deployment, the Kata Containers runtime asks a local hypervisor (QEMU/KVM) on the worker node to create a micro-VM for each pod; if the worker node is itself a VM, this requires nested virtualisation that the TEE hardware cannot provide. Peer Pods sidestep this entirely by moving the pod&amp;rsquo;s VM off the worker node and onto a separate, cloud-provisioned instance running directly on bare-metal TEE-capable hardware.&lt;/p&gt;</description></item><item><title>Trustee</title><link>https://lesitedefrancois.be/en/security/trustee/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/trustee/</guid><description>&lt;p&gt;&lt;strong&gt;Trustee&lt;/strong&gt; is the server-side attestation infrastructure for the &lt;strong&gt;CoCo (Confidential Containers)&lt;/strong&gt; 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.&lt;/p&gt;</description></item></channel></rss>