On Thu, Oct 22, 2026 at 11:02 AM Manuel Huber <[email protected]> wrote: > > 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
Thanks for the explanation. This clarifies a lot. Please include this context in the commit message and doc for v2. Also, one thing I missed earlier: before the policy verification call, please also check: ipe_keyring->restrict_link->check == restrict_link_reject so we make sure the restriction function is the right one. Fan
