Sealed image build UX + implementation

[jeckersb]

(Spawned from composefs-rs integration tracker)
(See also: containers/composefs-rs#143)

The repo for composefs-rs has many examples that sketch out proof-of-concept image builds. However, I think we need to improve on the user experience of building sealed images. It's gotta be something better than "copy and paste these example Containerfiles". So here's the place where we'll debate and design how this might work "for real".

My initial thought is to follow the prior art of the rechunker. Currently that's made up of a few parts:

• bootc-base-imagectl rechunk at the top-level, which ultimately calls...
• rpm-ostree compose build-chunked-oci

And then rechunk just takes --from and --to imgrefs and does the conversion automatically between the original and rechunked format. Ideally we should have a similar workflow for building sealed images:

• bootc-base-imagectl seal --from quay.io/example/my-img:unsealed --to quay.io/example/my-img:sealed that calls some new code like...
• bootc internals build-sealed-image (naming very bikesheddable)

And as a related note (this will eventually be spun-off into its own sub-issue) we'll need to expand bootc container lint to be able to lint sealed images.

[cgwalters]

We should give an example with the Secure Boot keys involved here but yep I think this is sane!

[allisonkarlitskaya]

I sort of like the approach as well. Huge bonus points if we could avoid having to do the second stage container build.

The actual work required to seal an image is basically to generate the UKI, injecting the appropriate composefs= argument into the commandline, sign that UKI, then store it in /boot. There's nothing stopping us from doing any of that outside of the container, assuming the correct tooling is available on the host. We could even do that as an operation on composefs's tree structure, but getting it back into the container world would be difficult. We don't even have support for creating layers in composefs. We've discussed push support in composefs in the past, but this would be a lot of work.

More realistically we should probably just shell out directly to buildah to derive the source image, adding the signed UKI to it, then committing to get our new image with the UKI included.

[allisonkarlitskaya]

Related: we also set the label for the (non-boot) fsverity integrity at the time we do this sealing step. This is the old cfsctl oci seal operation, but we'd do it in podman's world instead of our own.

[allisonkarlitskaya]

Also related: this is inspiring me to think again on producing image checksums without needing to import all of the files into the repository, which would speed things up dramatically. I have two approaches in mind for that. Let's discuss tomorrow.

[cgwalters]

The actual work required to seal an image is basically to generate the UKI,

I wonder if we should require the system to already be a UKI, and then we're just updating it with the digest? One issue here is there's lots of possible knobs for ukify and I am not sure we want to replicate those.

OTOH...I guess since ukify has a config file, we could have the user inject a config file that is processed by the default build.

[cgwalters]

We don't even have support for creating layers in composefs. We've discussed push support in composefs in the past, but this would be a lot of work.

Yes, though in lieu of direct push support, what the rpm-ostree container tooling does today is use https://docs.rs/ocidir/latest/ocidir/ to directly make an OCI - that can then be copied to containers-storage:.

(Obviously a lot more copying with that flow, but OTOH it also works around things like containers/buildah#4242 )

[allisonkarlitskaya]

Any chance of getting push support into containers-image-proxy-rs? I guess that would be a bit of an undertaking...

[allisonkarlitskaya]

Also: I don't think we have to worry about performance here. We're talking about adding a layer with a single file in it...

[cgwalters]

Any chance of getting push support into containers-image-proxy-rs? I guess that would be a bit of an undertaking...

Yes...the more I think about this more I think what we really want is a comprehensive cross-language binding to c/storage and c/image (soon future containers-libs https://blog.podman.io/2025/08/upcoming-migration-of-three-containers-repositories-to-monorepo/ )