On Mon, Oct 19, 2026 at 04:15:57PM -0700, Fan Wu wrote: > You might need to explain why the existing keyrings, i.e. > builtin/secondary/platform cannot be used in your scenario. Like the > firmware is not trusted?
As touched upon in [1], the scenario uses an ephemeral VM whose IEP policy would be assembled after boot. There is a mix of explicitly trusted dm-verity root hashes and possibly signed dm-verity layers which can vary per VM, so the final IPE policy would not necessarily be known ahead of time. This specific scenario is Kata Containers on Kubernetes. Each Kubernetes pod runs in a headless Kata VM with a static dm-verity protected rootfs, while its container image layers are delivered dynamically as dm-verity protected block devices. The kata-agent acts as trusted bootstrap userspace and would author the IPE policy for that particular guest before starting its workload containers. The firmware is trusted in this scenario. A public policy-signing certificate could be compiled into the builtin keyring or provisioned through the platform or secondary keyrings. Because the policy would be authored inside the guest, however, the corresponding private key would also have to be shipped as a static artifact in the guest rootfs and shared by every guest using that build. Instead, the kata-agent would generate an ephemeral, per-guest policy-signing key pair, provision its public certificate, sign the policy, destroy the private key, and restrict the keyring before allowing untrusted code to execute. A dedicated .ipe keyring thus provides a purpose-specific runtime provisioning path for this scenario. Once the certificate has been added, the keyring can be restricted against further enrollment. I envision other scenarios with similar characteristics may benefit from a dedicated .ipe keyring as well. I could elaborate more on this, e.g., on the how users' deployed container images translate to dm-verity protected image layers etc. (the erofs snapshotter is used and there is no filesystem sharing between host and guest, image layer transport is realized via block device attachment), but I am trying to keep this response brief. Some more breadcrumbs on the combination of containerd, IPE, Kata can be found in [2] and [3]. [1] https://lore.kernel.org/r/sj1pr12mb61246b0bf58bc2b6f0a79d30de...@sj1pr12mb6124.namprd12.prod.outlook.com [2] https://github.com/containerd/containerd/issues/12081 [3] https://github.com/kata-containers/kata-containers/issues/10943
