Multiple scope generation with a base image got from an openshift registry fails

[antechrestos]

Hi,

I am using kaniko and ended on an issue with openshift registries.

Going deeper, I spotted this was due to the fact I use a internal docker proxy

Here is my Dockerfile

FROM docker-internal-proxy/busybox:1.31.0

....

The push fails when kaniko does the bearer request with the scopes it deduced from the Layer of the image in the Write function

Indeed, given the above Dockerfile, it tries to authenticate with the given scopes:

• repository:test-kaniko/test-kaniko:push,pull
• repository:busybox:pull (unauthorized as it should have format <repo>/<image>)

If I use the following Dockerfile (without using the internal proxy

FROM busybox:1.31.0

....

It gives the scopes

• repository:test-kaniko/test-kaniko:push,pull
• repository:library/busybox:pull (given image busybox url is resolved as index.docker.io/library/busybox)

I removed the sending of all pull scope (the one for the base image) and kaniko push works well

My question: why are we sending also pull scope? If necessary, could we add for the write operation a fallback without the pull scopes deduced from the layers of the image ? Or even uniformizing the scopes to match the required format?

Thanks

[jonjohnsonjr]

Thank you for the detailed issue.

My question: why are we sending also pull scope?

I believe this was added to support cross-repo mounting. DockerHub expected the pull scope for any blobs you were trying to mount into your repository.

It seems like there is probably a bug here:

go-containerregistry/pkg/v1/remote/write.go

Lines 415 to 419 in 50b26ee

	// we add push scope for ref.Context() after the loop
	if ml.Reference.Context() != ref.Context() {
	scopeSet[ml.Reference.Context().Scope(transport.PullScope)] = struct{}{}
	}
	}

We shouldn't be adding scopes that aren't for the same registry, similar to how we don't attempt to cross-repo mount if the layers are in different registries: #219

I'm not sure how your internal docker proxy is set up, but it might be possible to convince kaniko to parse the reference differently by adding a library in there or even the internal proxy port? Are you pushing to the same registry as your base image?

[antechrestos]

@jonjohnsonjr thank you for your reply

Indeed my base image comes from docker hub through a docker proxy. Hence the target registry is not the same as the base image one.

I can make a pull request tomorrow if that is ok with you.

Regarding convincing kaniko I am not that familiar with it. I ended in this repository by reading the code. If we solve it in this repo and update the vendor library in kaniko it will solve my issue. But I agree with you that kaniko should have asked for scope for library/python instead of python in the first place.

[jonjohnsonjr]

I can make a pull request tomorrow if that is ok with you.

I'd love it! My plan was to update the logic here to check that ml.Reference.Context().Registry == ref.Context().Registry.