Override agent registry path

[carroarmato0]

When initializing Zarf to push its images to an external registry, I need to be able to use a specific path.

For example, on OpenShift, when using the Image Registry operator which provides a registry that you can use to push and pull your images from, OpenShift has a strict policy to store images in the following format: //

When using the following command, Zarf appends defenseunicorns/zarf/ before the agent image name.

zarf init --insecure --registry-push-password="$(oc whoami -t)" --registry-push-username="expert" --registry-url=image-registry.apps.<cluster_name>.<cluster_base_domain>/zarf --confirm

  ✔  Loading the Zarf State from the Kubernetes cluster                                                            
                                                                                                                   
 WARNING  Retrying (1/3) in 5s: GET
          https://image-registry.apps.<cluster_name>.<cluster_base_domain>/openshift/token?scope=repository%3Azarf%2Fdefenseunicorns%2Fzarf%2Fagent%3Apush%2Cpull&service=:
          unexpected status code 401 Unauthorized: {"details":"repository name
          \"zarf/defenseunicorns/zarf/agent\" invalid: it must be of the format
          \u003cproject\u003e/\u003cname\u003e"}

The expectation is to be able to have Zarf deploy its images in image-registry.apps.<cluster_name>.<cluster_base_domain>/zarf/agent

Is there currently a way to override this? Or is it necessary to create a Custom init package?

[lucasrod16]

Hey @carroarmato0, thanks for opening this issue.

Can you provide steps for a minimal reproduction of this error and provide as much context/information of your environment as possible?

[carroarmato0]

@lucasrod16 certainly, sorry for skipping the issue template, otherwise that would have been clearer.

So I'm evaluating Zarf on OpenShift 4.12 in an air-gapped environment.

There are two ways I've explored trying to get things to work.

Zarf using its internal docker registry

This should give the most flexibility due to the registry allowing multilevel container images to be saved and referenced.

For example:

• :5000/somecompanyname/mycoolproject/nginx
• :5000/someothercompany/traefik
• :5000/defenseunicorns/zarf/agent

On OpenShift I do bump into this issue: https://github.com/defenseunicorns/zarf/issues/2383#issuecomment-2078923106 This is because OpenShift does not allow the use of 127.0.0.1 (which is hardcoded in Zarf), but rather allows connecting using an IP of one of the nodes itself.

As long as this is hardcoded, this solution will not work.

Zarf using an external registry (OpenShift Image Registry)

OpenShift has this implementation called an Image Registry Operator. It's meant to allow you to self-host your container image registry and store images that can be built on the cluster itself and offers some additional features such as multi-tenancy whereby different users need to authenticate against their namespace.

For example: a user called "restricted-dev" only has access to their namespace/project called "twilightzone" in the cluster, which maps to the following path in the image registry: image-registry.mycluster:5000/twilightzone

The challenge here is.... this kind of Image Registry does not support multilevel paths.

So this will not work: image-registry.mycluster:5000/twilightzone/defenseunicorns/zarf/agent This will work: image-registry.mycluster:5000/twilightzone/agent

There are some additional challenges with this (general support for OpenShift, multitenancy, RBAC rules, etc...).

I don't think RedHat will be willing to change this behavior as it's a purposeful implementation and there are other mechanisms depending on the single container image layout per project.

Number 2) could be made possible in Zarf by allowing an overwrite of the destination of the container image to be pushed into a registry (but there might be some other challenges as well generally on OpenShift)

Number 1) is probably the easiest path as Zarf will be self-sufficient in managing the registry itself.

[carroarmato0]

Additionally. Since both pods are running within the same cluster, is there a reason to use 127.0.0.1: and not image: zarf-injector.zarf.svc:5000/library/registry:2.8.3 ?

[christianhuening]

I am having the same issue with a k3s setup on 4 nodes (raspberry PIs) using Cilium with the kube-proxy replacement and IPv6 DualStack setup. Currently I am trying to understand which part of that setup is preventing the usage of 127.0.0.1 as registry prefix