Feature Request: Allow for the configuration of private registries
Opened this issue · 2 comments
Is your feature request related to a problem?
We are running Rancher in an air-gapped environment, using a private registry. After moving to Rancher Prime, our installation points to a separate private registry which mirrors only the rancher prime images. Unfortunately, the Kubewarden helm chart doesn't allow us to independently point to a private registry. It will automatically use the systemDefaultRegistry or no registry at all (https://github.com/kubewarden/helm-charts/blob/main/charts/kubewarden-controller/templates/_helpers.tpl#L107-L113).
Solution you'd like
Just like you did for policy-reporter.image.registry, add these helm values so we can use a separate registry for the kubewarden images.
kubewarden-controller helm chart:
image.registry
kubewarden-defaults helm chart:
policyServer.image.registry
Alternatives you've considered
Create our own private registry which contains images for Rancher Prime and Kubewarden. However we'd rather keep those separated.
Anything else?
No response
Hi, thanks for opening this issue.
This definitely sounds like something that can be worked out. Yet, I'm not sure I fully understand the problem. Let me rephrase:
You have a Rancher air-gapped deployment, and have 2 private registries, one only for Rancher images (e.g: rancher-reg.example.com), and one for Kubewarden ones (e.g: kubewarden-reg.example.com).
One can set Kubewarden's global.cattle.systemDefaultRegistry to kubewarden-reg.example.com, just as any other value in Kubewarden's charts, and that should be sufficient, irrespective of the deployment values of Rancher charts that may be setting their global.cattle.systemDefaultRegistry to other value.
Hi, I had to double check, but it turns out that this issue is limited to RKE1. Although we set global.cattle.systemDefaultRegistry in the helm chart, the resulting value is still identical to the value we configured in our Rancher deployment (which is the rancher-prime mirror).
On our RKE2 clusters, it works as you described.