add support or verify support of OCI crypt

[cgwalters]

It'd be great to be sure we support OCI crypt; it'd greatly help use cases of embedding secret data inside a bootable container image. I need to dig into the flow for this.

Clearly for a bootc install style flow we'd need to have the provisioning system (e.g. cloud-init -> AMI or Anaconda) also be configured with decryption keys.

We should definitely still support secrets other ways too; I think support oci-crypt would be also be natural when we extend support for configmaps and particularly secrets.

[cgwalters]

cc @travier

[harche]

@cgwalters I had worked on adding the image encryption support for CRIO as well as skopeo.

I would love to take this up, if no one else has already started working on it.

[cgwalters]

@harche That'd be awesome!

[harche]

Notes. -

Potentially this decryptor can be used to decrypt the image layers.

[vrothberg]

I didn't fully read the code yet, so take my comment with a grain of salt.

Isn't bootc reading the layers directly from the Skopeo socket? So I think OCI crypt should work transparently because skopeo takes care of it.

Nice to see you again, @harche 👋

[harche]

@vrothberg good point, I haven't looked closely the bootc code. I was assuming it was written completely in rust which might require rust implementation of c/image to decrypt the images. But if it uses skopeo socket in the background then the task is much simpler.

[cgwalters]

Right, bootc depends on ostree-ext and that repo has the dependency graph for the architecture.

[harche]

Nice to see you again, @harche 👋

Nice to see you too @vrothberg :)

Right, bootc depends on ostree-ext and that repo has the dependency graph for the architecture.

@cgwalters @vrothberg does it make sense to use rust implementation of c/image instead of relying on the skope socket? If yes, I can create an issue and assign to me to track that work.

[cgwalters]

@harche see https://github.com/containers/containers-image-proxy-rs/#desired-containersimage-features

[cgwalters]

This thread also relates a bit to #128 - basically the direction we probably need to be moving instead is to share more code with c/storage too, which pushes us to extending the proxying between Rust ➡️ Go instead of using a new implementation. Basically we need lockstep features and integration with podman.

[vrothberg]

I very strongly urge to not rewrite the containers/image library in Rust or any other language. There's close to a decade of work behind and it's used in the entire RH ecosystem.

https://github.com/containers/containers-image-proxy-rs/#desired-containersimage-features mentions involving "containers/storage" but I do not understand what that means in detail (or what the problem is). The skopeo proxy (IIRC) happily returns the layers without going through storage. Also with composefs lurking around the corner, using c/storage may be the way forward.

[cgwalters]

I very strongly urge to not rewrite the containers/image library in Rust or any other language.

Well, the confidential computing folks already did - just not all of it. Anyways I think we're all in sync here.

[vrothberg]

confidential computing folks already did - just not all of it

Do you have a pointer? Curious to catch up on that.