Unable to use Gitlab container registry via zarf init

[hagak]

Environment

Device and OS: ubuntu linux x86 App version: 0.26.2 Kubernetes distro being used: k3s Other:

Steps to reproduce

1. Run zarf init --registry-push-password=XXXXX --registry-push-username=zarf --registry-url=registry.example.com/group/project

Expected result

Zarf init succedd

Actual Result

ERROR: unable to deploy all components in this Zarf Package: unable to deploy component zarf-agent: unable to deploy component zarf-agent: unable to push images to the registry: HEAD https://registry.example.com/v2/group/project/defenseunicorns/zarf/agent/blobs/sha256:a90984c6ecd16a551fa295c42528be562494cfcc8dde9879df0ad2e401c7076c: unexpected status code 401 Unauthorized (HEAD responses have no body, use GET for details)

Visual Proof (screenshots, videos, text, etc)

Severity/Priority

Additional Context

Zarf is trying to push up registry.example.com/group/project/defenseunicorns/zarf/agent:v0.26.2 Note that Gitlab will only allow container images of such format: group/project/first_level/second_level/name:tag

Zarf is attempting to add a third level. If you remove one of the added level (defensunicorns or zarf) it succeeds.

[Racer159]

Linking this to https://github.com/defenseunicorns/zarf/pull/1813 as another potential use case for hooks.

We have been looking at ways to support registry hosts with a variety of limitations (targeting ECR first as it doesn't even support push to create) - in your use case though would it be a fair assumption that you could give a service account to a service running in cluster that would pre-create the groups/projects correctly to maintain the correct level?

[hagak]

In this particluar case the issue is not pre-creating the proper structure it is that the zarf requires that the structure is set to /defenseunicorns/zarf/

If an external registry is provided it should not append the "/defenseunicorns/zarf". This allows for the end user to define the structure.

[Racer159]

That may require a separate feature to implement custom / user - controlled transform code, but is also doable.

For background, there are a few philosophies that Zarf has tried to balance with the current implementation leaning toward mirroring the upstream structures more closely since that allows applications (even non-k8s envs / envs without the Zarf Agent) to be changed to work offline relatively easily with only a domain swap (if the user is ok with the potential for tag collisions). In these cases ghcr.io/stefanprodan/podinfo:6.4.0 just becomes 127.0.0.1:31999/stefanprodan/podinfo:6.4.0. For Zarf Agent-enabled envs though we do also introduce a crc32 hash on the tag since docker.io/stephanprodan/podinfo:6.4.0 and ghcr.io/stefanprodan/podinfo:6.4.0 are separate images with different manifest shasums and in large envrionments you may wind up with images from a variety of sources (so ghcr.io/stefanprodan/podinfo:6.4.0 becomes 127.0.0.1:31999/stefanprodan/podinfo:6.4.0-zarf-2985051089).

Flattening the structure also works but would need hashing on the image repository name to avoid collisions / mixing of similarly named images (so ghcr.io/stefanprodan/podinfo:6.4.0 becomes 127.0.0.1:31999/zarf/podinfo-2985051089:6.4.0) which would be harder to calculate if folks needed / wanted to make manual updates.

As a new feature we could look at something similar to webpack's filename outputs where we let folks configure [name], [path], [tag], and [hash] with their own desired structure.

[Racer159]

(also here is where those transformations happen btw: https://github.com/defenseunicorns/zarf/blob/main/src/pkg/transform/image.go)