Task: proxy cache user story - Image pull commands and pod specs

[xaleeks]

This issue is a sub-task of the Proxy Cache epic (#11658)

Image Pull Commands and Pod Specs
【P0】As a user, I can pull from a remote registry by modifying my docker pull command to pull from the Harbor proxy cache acting as a proxy cache for the remote registry. However, I don’t want to have to edit the image path in my Kubernetes pod spec for that same purpose,
Ex. if my pod spec image path is the original target registry ‘gcr.io/libary/busybox:1.1
→ mutating webhook translate this to the harbor proxy project setup for it
If my pod spec image path is the configured proxy project ‘harbor/proxy1
→ it will pull directly from proxy

[xaleeks]

update on this, the final result for the 2.1 is that the pod manifest needs to be changed to point to the acting harbor proxy cache for that remote repository. We can think about this later on through some type of mutating webhook or other mechanism

[cnmcavoy]

If this was a mutating webhook, should it exist as part of a separate project from the primary harbor components? This mutating webhook might need to be deployed to kubernetes clusters which talk to a remote harbor and are not running any of the other harbor components.

[reasonerjt]

@cnmcavoy
correct.

[cnmcavoy]

I wrote up a mutating webhook that I am currently using to solve this problem at Indeed. I'd be happy to contribute it to harbor if you approve of the implementation, but I am not really clear on what the process for that would be. @reasonerjt in Slack you suggested discussing it on the next community meeting, is that the correct next step?

[reasonerjt]

Closing this issue as we decided to install the mutating webhook by harbor operator:
github.com/goharbor/harbor-operator