Scope issue on push with multiple sub-repositories in GCR about manifest-tool HOT 10 OPEN

Sure, thanks for asking! Sorry I didn't have time to test the scope yet, will try today

from manifest-tool.

What version of manifest-tool were you using? I can test this with my test GCR instance when I get a chance.

If you built from main in the last few weeks this was probably not working, but all released versions should work. I'm preparing to release v2.0.7 which has re-worked credential/Docker config support that isn't relying on the ORAS library import. I'll make sure to validate this working with GCR before releasing. I have already verified with DockerHub and AWS ECR.

from manifest-tool.

I was using mplatform/manifest-tool:alpine container image

from manifest-tool.

I was using mplatform/manifest-tool:alpine container image

Ah! This is most likely a limitation of using manifest-tool from within a container. If you installed the credential helper that is on the host and configured as such on the host. The container, unless you mount all the right places inside the container, has no idea about the credential helper. I believe if you try manifest-tool installed on the host you should find that it works properly.

It might be an interesting enhancement to add popular credential helpers to the container image, but there also might be additional steps (e.g. some cred helpers are going to want access to environment variables that are not set inside the container without specifically adding them) to get them to work properly.

from manifest-tool.

Nah this is part of a CI build, I installed the credential helper directly in the container. This container is running on a k8s cluster, so even if I wanted I wouldn't be able to install the helper on the host.

from manifest-tool.

Looks like this is not any issue with the credential helper anyway; I just verified/tested that there are no issues with using the GCR cred helper.

This might be a scope issue with the initial auth; looks like you are using subrepos for the "input" architectures? e.g. /multiarch-container/amd64 for 64-bit Intel, /multiarch-container/arm64 for ARM64v8, etc. The scope of the auth uses the initial repo (from the log: scope=\"repository:[redacted]/multiarch-container/amd64:pull\") and gets a token and is able to get the references needed from the amd64 image, but then it moves on to arm64 and uses the same token with the same scope and gets the 401. Not sure why I haven't seen this before as I have tested DockerHub at least with multiple repos as inputs. Let me dig a bit deeper

from manifest-tool.

Okay on my side I can try to push them in the same repo to confirm the issue. Thanks!

from manifest-tool.

It would be great if you could handle creds inside the container the way kaniko does. I'm trying to create a bunch of multi-architecture images with kaniko and write a single image_manifest.yaml for each one

---
image: registry/repo:123456-linuxarm64v8
platform:
  os: linux
  architecture: arm64
  variant: v8

which in a later stage, I want to gather those artifacts and merge them with yq then push them to my registry with manifest-tool.

yq ea '. as $item ireduce([]; . + $item) | {"image": env(IMAGE_URL), "tags": ("${TAGS}" | envsubst | split(" ")), "manifests": . }' image_manifests/* > manifest.yaml
manifest-tool push from-spec manifest.yaml

The problem is I don't know which registry the developers want this image to go to and I'd like manifest-tool to handle the auth rather than the infrastructure.

from manifest-tool.

@waddles seems reasonable to enhance the container with the cred helpers, but this issue has kind of morphed from what turns out the root cause was (looks like a scope issue in the auth transaction). I just opened a new issue (#216) to discuss/work towards better cred helper support when containerized, and, with @b4nst's approval, rename this issue to focus on the scope/authorizer issue.

from manifest-tool.