Consider changes to Proxy model

[mikebrow]

Just a heads up, we have a k8s SIG-Node WG that is considering significant changes to the CRI around image services.

Security image access policies, authentication with in proc local key rings vs over the RPC, GC cache polices, support for runtime handlers in the image service layer that choose which image to unpack from the image index (windows platform versions etc.,) and which snapshotter to use one per runtime handler, ...

For these and a number of other reasons we should chat about other potential ways to hook into the image services api.

Thought:

• extend the NRI to support image services at the CRI layer (something we've already been considering)
• some other way to extend sandboxes/the internal core image service tooling to support needed extension points

[elpdt852]

Hi @mikebrow thanks for the heads up. Is there a link or any documents that give more context around the proposed changes? I haven't been following too closely to the newer NRI / sandbox APIs but I'm happy to chat to learn more. I've contacted you on LinkedIn.

[elpdt852]

Hi @mikebrow, what ended up happening with image services? Anything I should be aware of?

For your context, when nix-snapshotter is running as an image service, it can pull images in two ways:

• Pull manifest from Docker Registry: This means trusting Docker Registry as a name resolution service, but the actual software packages are retrieved through Nix protocol which has its own security model and way of signing artifacts.
• Pull image from OCI tarball directly from Nix: This means there is no Docker Registry at all, and the image manifest along with software packages are retrieved through the Nix protocol. Nix doesn't natively have a "named reference" equivalent so would be something users will build on top of Nix and have its own security model.