Automatically Rewrite Container Image References in Kubernetes | Hacker News Reader

Automatically Rewrite Container Image References in Kubernetes

github.com

10 pointsflemzord9 comments

I wonder if you can build this into your container runtime config instead. Automatically rewriting is nice but you will still see the rewritten image when reading from the API server.

what I came to say. There's no reason this shouldn't be in the container runtime.

I'm not the biggest fan of mutating webhooks (vs validating ones), due to the fact that what you set is no longer what you see.

Now, its "cute" to be able to do it this way and the mutating webhook does solve a real problem by acting as a "virtualization layer", but that only really works if you want a write only system (which IMO somewhat defeats the point of kubernetes).

Now it could be that such a tool is valuable to motivate the need for this functionality to be actually be a configurable option within the container runtime, and without such a tool we wouldn't be able to really demonstrate the need.

I’ve developed a Kubernetes mutating admission webhook that intercepts Pod creation and update requests to automatically rewrite container image references based on configurable rules. This facilitates redirecting images from public registries (like Docker Hub, GCR, Quay.io) to internal mirrors or caches, enhancing reliability and security.

I thought this was possible to do with CEL but it looks like this has barely reached alpha: https://kubernetes.io/docs/reference/access-authn-authz/muta...

Webhooks like yours will still be needed for a while (or programmable frameworks like Kyverno).

How would this interact with IaC systems like ArgoCD - I imagine conflicts would be detected and ArgoCD would try to autosync to restore the cluster state to match the repo.

You can do this with containerd registry mirrors. The syntax of the rewrite rules is even the same.

Yeah curious what the benefit would be here vs configuring containerd mirrors https://github.com/containerd/containerd/blob/main/docs/host...

I guess if you don't control the platform you are running on this is a way to do it in "userspace"

Of course, being able to deploy this inside of Kubernetes itself is a huge boon.

It was a mistake to make the image registry and its configuration hosted outside the cluster. It makes no sense. You should be able to configure containerd registries effortlessly from inside the cluster.

Would this help in case of air gapped environments? You just run the registry in the internal network and use the rewrite. Am I right? Any catch?

Reply on news.ycombinator.com