3rd party packages on pkgs.k8s.io

[BenTheElder]

See additional context in #7708

cri-o packages depending on our CDN and being under of Kubernetes' package ISV was raised to SIG K8s infra long after it was announced publicly, however this still represents a regression both in conflating the security boundaries of publishing these packages and in the liability for end-user download traffic, the worst kind of uncapped liability that we've typically been asking projects to instead use e.g. github releases, avoiding digging that hole deeper. This was not discussed with SIG K8s Infra.

This is a problematic regression and represents inconsistent policy, I don't think we would have agreed to this or would agree to do this for other similar projects, we do not want to be liable for downloads for the entire Kubernetes landscape nor do we want to grant other projects access to our package ISV (even if currently the same people are doing both for both projects, we have to consider long term).

AFAICT this was never discussed or approved with SIG K8s Infra.

I suggest that we:

1. Stop publishing additional third party package builds, given these are a recent addition anyhow, to limit further adoption.
2. Leave the existing builds so as not to break users.
3. Signal boost whatever migration path cri-o publishes to their own package hosting.

See: #7708 for an umbrella tracking remaining third-party dependency on Kubernetes' resources, we've mostly but not-quite eliminated this since 2018.

/sig k8s-infra
cc @kubernetes/sig-k8s-infra-leads @kubernetes/release-engineering

[ameukam]

+1 for the general proposal. What would the ideal timeline to execute on this if we have consensus among the K8S Infra leads ?

[BenTheElder]

I suggest immediate halt to additional content publication (which is also already the case for the legacy CNI binaries GCS bucket), but an indefinite hold on any sort of removal of existing content -- hopefully we never need to do that.

Communication of alternatives for new releases would be pending input from cri-o maintainers. Prior to a few months ago users must have been using something else as Kubernetes wasn't hosting these, but we don't know what.

[saschagrunert]

cri-o packages depending on our CDN

If that's the main issue, could we then disable the CDN for https://pkgs.k8s.io/addons or an alternative domain?

If not, then we may switch over to the plain OBS URL's in our docs.

The CRI-O packaging configuration repo is there: https://github.com/cri-o/packaging

cc @kubernetes/sig-node-cri-o-test-maintainers

[BenTheElder]

I think it's similarly problematic to be under the same OBS ISV as outlined above.

[...] nor do we want to grant other projects access to our package ISV (even if currently the same people are doing both for both projects, we have to consider long term).

Aren't we conflating access to publish packages as Kubernetes / cri-o in addition to sharing the CDN after these are built?

From: https://kubernetes.io/blog/2023/10/10/cri-o-community-package-infrastructure/

isv:kubernetes:addons

Shouldn't this be isv:cri-o ?

Ideally access to OBS would be totally isolated as well, and the projects should be able to make different decisions about continued use in the future, with different but possibly overlapping sets of maintainer access.

[saschagrunert]

Shouldn't this be isv:cri-o ?

It could. Let's verify if OBS folks are happy with that as well.