Add non-core project "cri-readonly-proxy" to containerd organization

[vinayakankugoyal]

I'd like to propose adding cri-readonly-proxy to https://github.com/containerd organization as a non-core project. This proposal has no impact on the scope of the core project. This new project will be used to develop a utility that will act as a readonly proxy for containerd and cri grpc API. This was proposed as part of the following discussion https://github.com/containerd/containerd/issues/8085.

Proposed subproject maintainers:

• [x] @vinayakankugoyal
• [x] @samuelkarp
• [x] @hoskeri

containerd project governance requires 2/3 approval from core maintainers for the addition of new subprojects. With 11 core maintainers, 2/3 approval is 8:

• [ ] @AkihiroSuda
• [ ] @crosbymichael
• [ ] @dmcgowan
• [ ] @estesp
• [ ] @mikebrow
• [ ] @fuweid
• [x] @mxpv
• [ ] @dims
• [ ] @kevpar
• [x] @kzys
• [x] @samuelkarp

[samuelkarp]

has no impact on the scope of the core project

While I agree this does not increase the scope of the core project, we should note that the proxy will likely need to have some mechanism to keep up to date for API changes in the core project.

@vinayakankugoyal I don't see a list of proposed maintainers for the subproject here; can you add one? Proposed maintainers should acknowledge as well.

[hoskeri]

LGTM for maintaining this. Thanks!

[samuelkarp]

@vinayakankugoyal Thanks for adding proposed maintainers. I've updated the issue to capture votes from the core maintainers (and have approved this too).

[kzys]

Looks good to me. While we usually move projects from other organizations (see #131 and/or #83), rust-extensions was started like that apparently and I'm fine breaking the norm anyway. Just wanted to point out if people care that matter.

[mxpv]

LGTM

[AkihiroSuda]

Where is the current repo?

[vinayakankugoyal]

Where is the current repo?

We are creating the sub-project so that we can add the code there. I have a PoC but nothing concrete exists.

[AkihiroSuda]

Sorry, I can’t vote until the repo is ready, as the code maturity, license compliance, etc. matter to make a decision.

[samuelkarp]

@AkihiroSuda What are your concerns about license compliance? I think the idea here is to develop the code as part of the subproject rather than moving over existing code.

[AkihiroSuda]

Not specific to license, but non-existing code can't be evaluated.

I think I can likely vote in favor of this as soon as the POC repo is ready

[fuweid]

agree with @AkihiroSuda . There is no repository for evaluation. It sounds this project https://github.com/intel/cri-resource-manager

[mikebrow]

Yeah there are a few (ok more than a few) 3rd party cri proxies. I don't see a KEP for the reduced function CRI api. We already have an internal proxy that we've used in the past for versioning our CRI services internally, and that pattern would suffice to add an additional service export for read only without leaving us having to manage both. Additionally I'm concerned about encouraging even more CRI proxies and would prefer to have a more secure CRI auth mech eliminating the ability to have proxies between kubelet and containerd.. containerd and shims .. shims and runc... Here is the internal proxy as we saw it from the start https://github.com/containerd/containerd/blob/main/internal/cri/instrument/instrumented_service.go You can walk back to when we supported two versions of CRI at the same time to find an example of how we could support roCRI runtime and image services if that is the Kubernetes plan. It would be much simpler to add roCRI service there than it was to add two different versions of CRI at the same time.

[mikebrow]

The "other" proxies I know of should no longer be needed as the parties migrate to NRI..

[vinayakankugoyal]

Thanks @mikebrow. Ideally it would be great to if this was part of containerd. While kubelet would still need access to rwCRI, there are many security monitoring tools that can benefit from there being a readonly service that they can talk to.

We discussed making this a part of containerd vs proxy here: https://github.com/containerd/containerd/issues/8085

[mikebrow]

security monitoring as a ro (lower privilege?) .. would be nice to have a wg discussion on it. We have a plan of action to move all cadvisor metrics into CRI.. Would metrics suffice for the various type of security monitoring you are considering?

[mikebrow]

We discussed making this a part of containerd vs proxy here: containerd/containerd#8085

Lots of pros/cons; external proxy with hops and it's own external (to containerd and kubelet?) security controls vs internal with a new internal security access model. I think we are missing some auth info for the CRI context that would be needed here to implement inside or outside the cri plugin unless prototyping with annotations, thus suggesting either we would add a new service connection api for or modify CRI.

There is also a tenancy issue to consider. Should the client authorized at a user level only be able to access a subset of the pods/images..

Side note: sig-auth is helping on the ensure secret pulled images KEP for k8s 1.33 (didn't quite make it for k8s 1.32): https://github.com/kubernetes/kubernetes/pull/128152 .. ** What this ^ feature is doing is restricting access to container images on a per pod basis, they have to have the right creds in the pod spec or a node level keyring, while also allowing a finer grained use of keyrings than the prior node wide only use case. Today the alternative to ^ is you "pull always" to verify this pod (possibly another user/tenant also has the creds to access the image.

Either way inside or external with a hop, this will be a fun set of discussions :)