Kaniko supporting multiple auths

[webmutation]

Actual behavior
Currently using A private pull and a private push registry. So user needs to be logged in to both private registries.
Currently when building i get
"No matching credentials were found, falling back on anonymous"

Expected behavior
What is the proper usage for pulling images from docker hub.

To Reproduce
Steps to reproduce the behavior:

1. create private registry for pull
2. create private registry for push
3. create auth for pushing
4. build image
5. see notification "No matching credentials were found, falling back on anonymous" 3x

does the kaniko debug image perform a docker login under the hood... how should I pass it the information?

[jubel-han]

Depending on where you are performing the executor, normally, you will need to mount the docker auth config.json under the directory of /kaniko/.docker/ according to here.

[webmutation]

It is mounted I even inject the same config file I use locally
cat config.json > /kaniko/.docker/config.json

The problem seems to be that it does not recognize more than one registry at a time... so if you have a pull and a push registry that are different say you want to pull from docker hub (as a logged in user, anonymous works) and push to your private registry it will not work... at least this has been my experience using Kaniko with a gitlab docker runner.

I worked around by pulling from a mirror repository that contained docker hub and my own private registries, so I don't have a blocking issue, its the behavior from kaniko that does not seem correct to me. It should be able to take all the configuration passed, meaning all auth tokens for the respective registries.

[MCyprien]

I have the same kind of problem, I try to publish my container to the gitlab registry and gcr, individually it work, but not with both of them.

Build Docker image:
  stage: build
# Using debug image for gitlab-ci purpose https://docs.gitlab.com/ee/ci/docker/using_kaniko.html
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.10.0
    entrypoint: [""]
  script:
    - export GOOGLE_APPLICATION_CREDENTIALS="$(pwd)/my_gcr_creds.json"
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json 
    - /kaniko/executor --context $(pwd) --dockerfile ./Dockerfile --destination $GCR_REPO --destination $GITLAB_DOCKER_REPO

[AASanchezA]

any update on this issue, I need to pull from private registry and need to push to aws

[raphaelLacerda]

any status on this feature request?

[edvald]

@AASanchezA I'd expect you could mount or otherwise write the /kaniko/.docker/config.json JSON file as suggested, and just have two keys under auths, one for each registry. Did you try that? I'm working on supporting this in https://github.com/garden-io/garden and until I find out otherwise, I'm going on the assumption you can put multiple auths in that file, same as when you configure docker locally.

[AASanchezA]

@edvald at the end i solved running two separate jobs on my gitlab-ci.yml one for registry that i need to push the container image, this is working quit well but the image is been build two times

[gawi]

If the goal if to be able to publish to GCR and to something else, this is absolutely feasible by providing two auth entries in config.json. You would need to authenticate to GCR using a JSON key file.

What you can't do is to publish to multiple GCR projects having different credentials because the authentication key is the hostname. You would have more than one entry under gcr.io. It wouldn't work. As a work-around, you could try to use CNAMEs for gcr.io such as us.gcr.io.

[Shanuson]

@gawi how does the config.json looks like in this case? What would be the content of the auth field for gcr:

{
  "auths": {
    "some docker registry url": {
      "auth": "a key"
    },{
    "eu.gcr.io":{
    ?? what should be here ??
    }
  }
}

[gawi]

@Shanuson Assuming you use the JSON key file method to authenticate to GCR:

{
  "auths": {
    "https://asia.gcr.io": {
      "username": "_json_key",
      "password": "<JSON service account key #1 properly escaped>"
    },
    "https://eu.gcr.io": {
      "username": "_json_key",
      "password": "<JSON service account key #2 properly escaped>"
    },
    "https://gcr.io": {
      "username": "_json_key",
      "password": "<JSON service account key #3 properly escaped>"
    },
    "https://us.gcr.io": {
      "username": "_json_key",
      "password": "<JSON service account key #4 properly escaped>"
    }
  }
}

And the repositories can then be:

• asia.gcr.io/project1/xyz
• eu.gcr.io/project2/xyz
• gcr.io/project3/xyz
• us.gcr.io/project4/xyz

Each of them can have a different account key. Obviously, this is a hack, it doesn't scale and you are at the mercy of the CNAME entries on the Google side. This is a last resort solution.

[webmutation]

As far as I can tell this works. I have two registries I would like to push the same image to both

In config.json

{"auths":
	"registrya.org":
		{"username":"usera","password":"[MASKED]"}
	},
	"registryb.com":
		{"username":"userb","password":"[MASKED]"}
	}
}

         /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile \
         --build-arg IMAGE_DATE="$(date --utc +%Y-%m-%dT%H:%M:%SZ)" \
         --destination $CIA_REGISTRY/$CI_REGISTRY_IMAGE:mock \
         --destination $CIB_REGISTRY/$CI_REGISTRY_IMAGE:mock

This prevents the dual build. I did not test with tokens or other types of registries in this case both CIA and CIB are Nexus registries.

[seboudry]

If you want to push to GCR using a JSON key file and also to other registries, you must define config.json file with gcr credential helper alongside with other auths registry credentials.

Example with https://docs.gitlab.com/ee/ci/docker/using_kaniko.html and also GCR:

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  variables:
    GOOGLE_APPLICATION_CREDENTIALS: /path/to/key.json
  script:
    - |
      cat <<EOF > /kaniko/.docker/config.json
      {
        "auths": {
          "$CI_REGISTRY": {
            "username": "$CI_REGISTRY_USER",
            "password": "$CI_REGISTRY_PASSWORD"
          }
        },
        "credHelpers": {
          "eu.gcr.io": "gcr"
        }
      }
      EOF
    - >
      /kaniko/executor
      --context $CI_PROJECT_DIR
      --dockerfile $CI_PROJECT_DIR/Dockerfile
      --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
      --destination eu.gcr.io/gcp-project/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA

[tmshn]

Yeah @seboudry's solution looks right; the kaniko docker image has docker-credentials-gcr and it will be configured only if no config file exists.

Maybe this should work too:

cat <<EOF > /kaniko/.docker/config.json
{
  "auths": {
    "$CI_REGISTRY": {
      "auth": "$BASE64_ENCODED_USERNAME_AND_PASSWORD"
    }
  }
}
EOF
docker-credential-gcr configure-docker

---

Note that the above example is for GitLab CI. If you use Google Cloud Build, the config file should be something like:

steps:
- name: gcr.io/kaniko-project/executor:debug
  entrypoint: sh
  args:
  - -cx
  - |
    cat <<EOF > /kaniko/.docker/config.json
    {
      "auths": {
        "$CI_REGISTRY": {
          "auth": "$BASE64_ENCODED_USERNAME_AND_PASSWORD"
        }
      }
    }
    EOF
    docker-credential-gcr configure-docker
  volumes:
  - name: kaniko-docker-config
    path: /kaniko/.docker
- name: gcr.io/kaniko-project/executor:latest
  args: [ ... ] # as usual
  volumes:
  - name: kaniko-docker-config
    path: /kaniko/.docker

[sneko]

Hi,

Sorry if that's not the right place to post but does anyone have successfully authenticated Kaniko to GCR with the JSON key?

Before I was using Docker CLI... then img (that works great, except for a specific pipeline that times out so I need to move just this one to Kaniko). And it was pretty easy to make things authenticated:

cat $IMAGE_REGISTRY_KEYFILE | img login -u _json_key --password-stdin $IMAGE_REGISTRY_URL

But with Kaniko, impossible to succeed for now. I followed https://github.com/GoogleContainerTools/kaniko#pushing-to-google-gcr and my service account is mounted in my CI/CD, and even by doing:

                    sh 'export GOOGLE_APPLICATION_CREDENTIALS=$IMAGE_REGISTRY_KEYFILE'
                    sh '/kaniko/executor --context `pwd` --destination $IMAGE_TAG:latest'

I'm always facing an "Access denied" whereas with img it works.

I guess I missed something but I don't understand what. I still have the solution of creating the /kaniko/.docker/config.json but since I'm using _json_key as a user, how to easily format the file while escaping the service account quotes into the shell of the Kanifo image? (all above examples of config.json creation are done with user/password way, so nothing to escape in theory)

Thank you,

[sneko]

It was a mistake from me...

Exporting the environment variable in a different step was not persisted to the Kaniko build step. The solution was to directly populate GOOGLE_APPLICATION_CREDENTIALS as I did for IMAGE_REGISTRY_KEYFILE : by setting this variable on the pipeline container.

Sorry for disturbing,

[richardmatthewsdev]

Has there been any update on this issue?

With the recent change to the Docker Pull Limit I am needing to be able to pull the base image from Docker Hub as an authenticated user so that I can build my Docker Image which is then pushed up to our own private registry in ECR.

[Wykiki]

Hello, I just encountered the problem here, with the need to pull in image from repository A and then push the built image to repository B, both registries having the same hostname.

I have a config.json like this :

{
    "auths": {
        "example.com/registryA": { // Pull
            "username": "userA",
            "password": "passA"
        },
        "example.com/registryB": { // Push
            "username": "userB",
            "password": "passB"
        }
    }
}

Using CNAMEs as a workaround is not possible.
So am I stuck copying the pulled image to the same registry as the one being pushed on ?

[webmutation]

Hi @Wykiki, no... the config json is simply to provide the credentials.
When you push you can define your push registry... you can even have multiple ones... let me show you an example from Gitlab file:

         /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/packages/$PKG/deploy/Dockerfile \
         --build-arg IMAGE_DATE="$(date --utc +%Y-%m-%dT%H:%M:%SZ)" \
         --build-arg VCS_REVISION=$PKG_COMMIT_SHA \
         --build-arg VCS_SEMVER=$PKG_VERSION \
         --build-arg PKG_WORKDIR=/packages/$PKG \
         --destination $PUSHREGA_REGISTRY/$PKG:$PKG_VERSION \
         --destination $PUSHREGB_REGISTRY/$PKG:latest

[rufreakde]

Since I stumbled across this issue and I think it is a little bit related I will share what worked for me:

echo -n <USERNAME>:<PASSWORD> | base64

And the format of the config.json:

{
    "auths": {
        "example.com/registryA": {
            "auth":"<BASE64_RESULT>"
        },
        "example.com/registryB": {
            ...
        },
   ...
    }
}

[patrikbeno]

Kaniko version : v1.6.0

It looks like Kaniko considers only first entry in config.json.

I can successfully pull base image from authenticated registry, and push back the result image & cache layers.

Simply reordering items in config.json breaks the build.
Yes, JSON is valid.

[farvour]

I'm also having this problem. I am discontinuing using kaniko and fell back to regular, limited docker builder hosts using Docker-in-Docker, or remote via SSH when isolation is required, since this is such a blocker when it comes to Kaniko. I guess this is what you trade off when kaniko basically has to re-invent the whole auth wheel. :(

[tskibinski]

I ran into the same problem. I want to push the same version of the image from CI/CD pipeline to Docker Hub and ECR.
My current workaround is to get creds to ECR first, re-format them and save in .docker/config.json under the auths section:

ecr_secret=$(echo "$AWS_ECR_URL" | /kaniko/docker-credential-ecr-login get | sed -n 's/.*"Secret":\([^}, ]*\).*/\1/p' | tr -d '"')
ecr_auth=$(echo "AWS:$ecr_secret" | base64 | tr -d '\n')

echo "{\"auths\":{\"https://index.docker.io/v1/\":{\"auth\":\"$(echo -n ${DOCKER_HUB_USER}:${DOCKER_HUB_PASS} | base64 | tr -d '\n')\"},\"$AWS_ECR_URL\":{\"auth\":\"$ecr_auth\"}}}" > /kaniko/.docker/config.json

[mtcolman]

Hi, this impacts me too. I've tried reading through the code, but I can't work out where the code is that only reads the first item in config.json...

[jasonyic]

Hi, in case anyone run into the following case:

• Pull from and Push to private registry, from and to registry are different

if AWS ECR involved, using instance role permission, and no need to add anything to config.json. if other private registry, add the following

{"auths": { registry-A: {"auth": "AUTH_A_BASE64ED"} , registry-B: {"auth": "AUTH_B_BASE64ED"} }}

kaniko used: v1.7.0
hope this helps.

[imjasonh]

I also have been trying with similar to the below for pulling from one private registry then pushing to a different private registry and no success:
...
For now am moving back to using docker commands for this.

FWIW, docker itself doesn't seem to support this layout of the "auths" section, at least not as far as I could tell from my testing. I proposed a PR to the library kaniko uses for auth (google/go-containerregistry#1280) and it seems that's still an open feature request in Docker: docker/cli#2928

---

For configuring and using different auth for different registries, Kaniko should already support that, and if it doesn't, that's definitely a bug. But for different repos within the same registry, I'm afraid there's not a lot we can do unless we diverge from Docker's behavior.

[jonathanmedd]

@imjasonh Thanks for the info, very useful. I can confirm that we are able to use different auth with different registries:

{
    "auths": {
        "registry1.com": { // Pull
            "username": "userA",
            "password": "passA"
        },
        "registry2.com": { // Push
            "username": "userB",
            "password": "passB"
        }
    }
}

That gives us more of the flexibility we were looking for.

[imjasonh]

It sounds like this issue is resolved, please respond or file a new issue if this isn't the case.

[mtcolman]

I don't believe it's resolved. @jonathanmedd's statement just means that 1 of the 2 use cases mentioned below work:

• multiple auths, multiple registries = works
• multiple auths, mutliple repositories with same registry doesn't work

I guess the question is, does Kaniko want to provide the latter...?

[ghost]

multiple auths, mutliple repositories with some registry doesn't work

Just FTR, this does not "not work" in all possible scenarios. kaniko works nicely for us with setups where for example AWS ECR access is constrained by IAM roles for different kaniko nodes or even by available AWS credential per kaniko CI job if you use AWS SDK profiles (supported by the ecr-login credential helper). The capabilities of AWS IAM strip away the need to deal with subpaths/repositories in the "Docker" configuration. Of course it'd be nice to have this work in the general case, through from an engineering perspective, you could always provide a registry proxy to map different domain names to URI paths. Ive seen this in practice as well (https://registry.whateverproxy.internal => https://bigserver.com/registry/) Might even be preferable in more locked down environments.

[imjasonh]

• multiple auths, mutliple repositories with same registry doesn't work

In this case, I don't think Kaniko should extend to support this, since docker CLI doesn't support this today either AFAIK.

[mtcolman]

Yes, unfortunately docker appears to have this limitation:

$ sudo docker image ls
REPOSITORY    TAG       IMAGE ID       CREATED        SIZE
hello-world   latest    feb5d9fea6a5   4 months ago   13.3kB

$ sudo docker tag hello-world uk.icr.io/myrepoone/hello-world:1

$ sudo docker image ls
REPOSITORY                        TAG       IMAGE ID       CREATED        SIZE
hello-world                       latest    feb5d9fea6a5   4 months ago   13.3kB
uk.icr.io/myrepoone/hello-world   1         feb5d9fea6a5   4 months ago   13.3kB

$ sudo docker tag hello-world uk.icr.io/myrepotwo/hello-world:1

$ sudo docker image ls
REPOSITORY                             TAG       IMAGE ID       CREATED        SIZE
hello-world                            latest    feb5d9fea6a5   4 months ago   13.3kB
uk.icr.io/myrepoone/hello-world        1         feb5d9fea6a5   4 months ago   13.3kB
uk.icr.io/myrepotwo/hello-world        1         feb5d9fea6a5   4 months ago   13.3kB

$ sudo docker push uk.icr.io/myrepoone/hello-world:1
The push refers to repository [uk.icr.io/myrepoone/hello-world]
e07ee1baac5f: Preparing
unauthorized: The login credentials are not valid, or your IBM Cloud account is not active.

$ sudo docker push uk.icr.io/myrepotwo/hello-world:1
The push refers to repository [uk.icr.io/myrepotwo/hello-world]
e07ee1baac5f: Preparing
unauthorized: The login credentials are not valid, or your IBM Cloud account is not active.

$ sudo docker login -u iamapikey -p [redacted] uk.icr.io/myrepoone
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded

$ sudo docker login -u iamapikey -p [redacted] uk.icr.io/myrepotwo
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded

$ sudo docker push uk.icr.io/myrepoone/hello-world:1
The push refers to repository [uk.icr.io/myrepoone/hello-world]
e07ee1baac5f: Preparing
denied: insufficient scope

$ sudo docker push uk.icr.io/myrepotwo/hello-world:1
The push refers to repository [uk.icr.io/myrepotwo/hello-world]
e07ee1baac5f: Pushed
1: digest: sha256:f54a58bc1aac5ea1a25d796ae155dc228b3f0e11d046ae276b39c4bf2f13d8c4 size: 525

$ sudo docker login -u iamapikey -p [redacted] uk.icr.io/myrepoone
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded

$ sudo docker push uk.icr.io/myrepoone/hello-world:1
The push refers to repository [uk.icr.io/myrepoone/hello-world]
e07ee1baac5f: Pushed
1: digest: sha256:f54a58bc1aac5ea1a25d796ae155dc228b3f0e11d046ae276b39c4bf2f13d8c4 size: 525

However I can do this with podman (I'm already logged into both repos)...

$ podman pull hello-world
Resolved "hello-world" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob 2db29710123e done
Copying config feb5d9fea6 done
Writing manifest to image destination
Storing signatures
feb5d9fea6a5e9606aa995e879d862b825965ba48de054caab5ef356dc6b3412

$ podman image ls
REPOSITORY                     TAG         IMAGE ID      CREATED       SIZE
docker.io/library/hello-world  latest      feb5d9fea6a5  4 months ago  19.9 kB

$ podman tag docker.io/library/hello-world:latest uk.icr.io/myrepoone/hello-world:2

$ podman tag docker.io/library/hello-world:latest uk.icr.io/myrepotwo/hello-world:2

$ podman image ls
REPOSITORY                            TAG          IMAGE ID       CREATED         SIZE
docker.io/library/hello-world         latest       feb5d9fea6a5  4 months ago  19.9 kB
uk.icr.io/myrepoone/hello-world       2            feb5d9fea6a5  4 months ago  19.9 kB
uk.icr.io/myrepotwo/hello-world       2            feb5d9fea6a5  4 months ago  19.9 kB

$ podman push uk.icr.io/myrepoone/hello-world:2
Getting image source signatures
Copying blob e07ee1baac5f done
Copying config feb5d9fea6 done
Writing manifest to image destination
Storing signatures

$ podman push uk.icr.io/myrepotwo/hello-world:2
Getting image source signatures
Copying blob e07ee1baac5f done
Copying config feb5d9fea6 done
Writing manifest to image destination
Storing signatures

[imjasonh]

However I can do this with podman (I'm already logged into both repos)...

Interesting! Can you tell whether/how these separate auths are configured in Podman's auth config, in ${XDG_RUNTIME_DIR}/containers/auth.json?

If there's precedent for Podman supporting this, then it might be easier to justify changing that behavior for Kaniko, and possibly even other go-containerregistry consumers.

edit: podman login docs seem to indicate that you login to a registry, and not a specific repository -- did you podman login uk.icr.io/myrepoone etc?

[mtcolman]

However I can do this with podman (I'm already logged into both repos)...

Interesting! Can you tell whether/how these separate auths are configured in Podman's auth config, in ${XDG_RUNTIME_DIR}/containers/auth.json?

If there's precedent for Podman supporting this, then it might be easier to justify changing that behavior for Kaniko, and possibly even other go-containerregistry consumers.

edit: podman login docs seem to indicate that you login to a registry, and not a specific repository -- did you podman login uk.icr.io/myrepoone etc?

Yes, because my API keys are scoped to each repository (so I must be logged into both).

[mtcolman]

@imjasonh apologies - it took me a while to find them - I'm on Ubuntu on WSL2 and ${XDG_RUNTIME_DIR} doesn't exist. I have managed to find the location: /tmp/podman-run-1000/containers/auth.json and it contains:

{
        "auths": {
                "uk.icr.io/myrepoone": {
                        "auth": "<redacted-base64-string-of-user-and-password-for-myrepoone>"
                },
                "uk.icr.io/myrepotwo": {
                        "auth": "<redacted-base64-string-of-user-and-password-for-myrepotwo>"
                }
        }
}

[mtcolman]

@imjasonh should this issue be reopened?

[imjasonh]

Yep. I've reopened google/go-containerregistry#1280 to discuss supporting this in go-containerregistry, which we'd then update here, and in other tools that use that library.

[anishvt20]

The following configuration works for us

Gitlab and ECR registry auth

{ "auths": { "$CI_REGISTRY": { "username": "$CI_REGISTRY_USER", "password": "$CI_REGISTRY_PASSWORD" } }, "credHelpers": { "$REGISTRY_URL": "ecr-login" } }

I use Gitlab and AWS ECR as docker registries and transitioning to use AWS ECR in the future.
The issues reported here are related to different Kaniko images. Finally found out the following image works

gcr.io/kaniko-project/executor@sha256:939b0a1a0aaad97a06db665291ac2270a9abe538af4198000046f743d1e61cd4

[imjasonh]

@mtcolman Please see #1939

I've built and pushed images using that code at

gcr.io/imjasonh/executor:latest@sha256:39d92d2819fbde4455a10ec8ae86d2fa6e1f245f3a074672445bc2fdfeeeb7d9
gcr.io/imjasonh/executor:debug@ sha256:74f70c706c0896fce7b04fbb0afbefdbad0db77c113ab721d2640739f9ac6e3d

If you get a chance please try them out and let me know if those do/don't work for you 👍

[mtcolman]

@imjasonh I'm afraid it didn't work:

step-merge-json

Sorting out config.json for Kaniko.
Files /home/.dockerwip/base.dockerconfigjson and /home/.dockerwip/build.dockerconfigjson differ

Merging docker config.json files into single file.

Finished merging docker config.json files into single file.

Finished sorting out config.json for Kaniko.
{
  "auths": {
    "uk.icr.io/myrepoone": {
      "username": "iamapikey",
      "password": "<redacted>",
      "email": "unused",
      "auth": "<redacted>"
    },
    "uk.icr.io/myrepotwo": {
      "username": "iamapikey",
      "password": "<redacted>",
      "email": "unused",
      "auth": "<redacted>"
    }
  }
}

End.

step-build
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for "uk.icr.io/myrepotwo/simple-page:example-pipeline-test-multiple-auth-7xzukx": POST https://uk.icr.io/v2/myrepotwo/simple-page/blobs/uploads/: DENIED: insufficient scope; [map[Action:pull Class: Name:myrepotwo/simple-page Type:repository] map[Action:push Class: Name:myrepotwo/simple-page Type:repository]]

(I'm running this via Tekton on OpenShift, using: image: gcr.io/imjasonh/executor:latest@sha256:39d92d2819fbde4455a10ec8ae86d2fa6e1f245f3a074672445bc2fdfeeeb7d9)

[mtcolman]

I've also tried gcr.io/imjasonh/executor:debug@sha256:74f70c706c0896fce7b04fbb0afbefdbad0db77c113ab721d2640739f9ac6e3d locally, mounting the credentials file in and it's failing.

podman run -it --entrypoint=/busybox/sh -e "DOCKER_CONFIG"="/kaniko/.docker/" -v /path/to/code-repo:/code-repo -v /path/to/dir/containing-config.json/:/kaniko/.docker/ gcr.io/imjasonh/executor:debug@sha256:74f70c706c0896fce7b04fbb0afbefdbad0db77c113ab721d2640739f9ac6e3d

Ran this command:

/kaniko/executor --dockerfile=/code-repo/Dockerfile --destination=uk.icr.io/myrepotwo/mytest:1 --context=/code-repo/ --single-snapshot=true --image-name-with-digest-file=/workspace/image-digest

(And yes, I have checked the credentials outside of Kaniko and they allow me to push/pull as required - sorry!)

[davidgiga1993]

Was someone able to use #1939?
It's also not working me. Using the same domain with two different auths:

{
  "auths": {
    "registry.internal/namespaceA": {
      "username": "test",
      "password": "<redacted>"
    },
    "registry.internal/namespaceB": {
      "username": "test",
      "password": "<redacted>"
    }
  }
}

@imjasonh I see that you MR states Unit tests and or integration tests added. as reviewer note, but to me it looks like there are no tests included?

Update:
I've noticed that it's random and depending on the push order.
Using the above configuration, when calling kaniko with

--destination registry.internal/namespaceA/image:latest  \
--destination registry.internal/namespaceB/image:latest 

kaniko will sometimes start pushing to the namespaceA repo and sometimes to the namespaceB repo.
When the first push is to namespaceB the push will fail due to invalid credentials.

[imjasonh]

I'm not sure why those boxes were ticked, I don't believe I did that. Or if I did, it was a mistake. There are indeed no tests for this.

I'll reopen this since it seems the fix in go-containerregistry doesn't address the issue here. If anybody has more time to look into this that would be helpful, it may take me some time to get back to it.

[TeChn4K]

A little tip for people with the same need as I have (be able to read/write multiple GCloud Registries) it is possible to use an unique service account with permissions on multiple projects.

So for example, for only one service account :

• https://eu.gcr.io/registry_A : read
• https://eu.gcr.io/registry_B : read/write

.docker/config.json would look like:

{
  "auths": {
    "https://eu.gcr.io": {
      "username": "_json_key",
      "password": "<service account json key>"
    }
  }
}

No need to use multiple auth as you use one single domain.

[shakthivnot]

It sounds like this issue is resolved, please respond or file a new issue if this isn't the case.

I've also faces same error when using different using two different container registry in azure. I am using the config.json file as below but fires error

For verbose messaging see aws.Config.CredentialsChainVerboseErrors
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for ".azure**.io//**:21": creating push check transport for ******.azure.io failed
Was that config.json file aruguments correctly created?

{
"auths": {
"registry1.com": { // Pull
"username": "userA",
"password": "passA"
},
"registry2.com": { // Push
"username": "userB",
"password": "passB"
}
}
}

[mansenfranzen]

The following configuration works for us

Gitlab and ECR registry auth

{ "auths": { "$CI_REGISTRY": { "username": "$CI_REGISTRY_USER", "password": "$CI_REGISTRY_PASSWORD" } }, "credHelpers": { "$REGISTRY_URL": "ecr-login" } }

I use Gitlab and AWS ECR as docker registries and transitioning to use AWS ECR in the future. The issues reported here are related to different Kaniko images. Finally found out the following image works

gcr.io/kaniko-project/executor@sha256:939b0a1a0aaad97a06db665291ac2270a9abe538af4198000046f743d1e61cd4

This helped me solve the issue with pulling images from ECR and pushing to Harbor docker registry at the same time. Thanks for the hint!