Coder Social home page Coder Social logo

googlecloudplatform / docker-credential-gcr Goto Github PK

View Code? Open in Web Editor NEW
279.0 35.0 88.0 1.33 MB

A Docker credential helper for GCR users

Home Page: https://gcr.io

License: Apache License 2.0

Go 92.76% Starlark 7.24%
docker-client docker gcloud gcloud-sdk docker-registry docker-image-registry docker-images compute-engine

docker-credential-gcr's Introduction

docker-credential-gcr Build Status Go Report Card

Introduction

docker-credential-gcr is Google Container Registry's standalone, gcloud SDK-independent Docker credential helper. It allows for v18.03+ Docker clients to easily make authenticated requests to GCR's repositories (gcr.io, eu.gcr.io, etc.).

Note: docker-credential-gcr is primarily intended for users wishing to authenticate with GCR in the absence of gcloud, though they are not mutually exclusive. For normal development setups, users are encouraged to use gcloud auth configure-docker, instead.

The helper implements the Docker Credential Store API, but enables more advanced authentication schemes for GCR's users. In particular, it respects Application Default Credentials and is capable of generating credentials automatically (without an explicit login operation) when running in App Engine or Compute Engine.

For even more authentication options, see GCR's documentation on advanced authentication methods.

GCR Credentials

By default, the helper searches for GCR credentials in the following order:

  1. In the helper's private credential store (i.e. those stored via docker-credential-gcr gcr-login)
  2. In a JSON file whose path is specified by the GOOGLE_APPLICATION_CREDENTIALS environment variable.
  3. In a JSON file in a location known to the helper:
    • On Windows, this is %APPDATA%/gcloud/application_default_credentials.json.
    • On other systems, $HOME/.config/gcloud/application_default_credentials.json.
  4. On Google App Engine, it uses the appengine.AccessToken function.
  5. On Google Compute Engine, Kubernetes Engine, and App Engine Managed VMs, it fetches the credentials of the service account associated with the VM from the metadata server (if available).

Users may limit, re-order how the helper searches for GCR credentials using docker-credential-gcr config --token-source. Number 1 above is designated by store and 2-5 by env (which cannot be individually restricted or re-ordered). Multiple sources are separated by commas, and the default is "store, env".

While it is recommended to use gcloud auth configure-docker in gcloud-based work flows, you may optionally configure docker-credential-gcr to use gcloud as a token source (see example below).

Examples:

To use only the gcloud SDK's access token:

docker-credential-gcr config --token-source="gcloud"

To search the environment, followed by the private store:

docker-credential-gcr config --token-source="env, store"

To verify that credentials are being returned for a given registry, e.g. for https://gcr.io:

echo "https://gcr.io" | docker-credential-gcr get

Other Credentials

As of the 2.0 release, docker-credential-gcr no longer supports generalized credsStore functionality.

Building from Source

The program in this repository is written with the Go programming language and can be built with go build. These instructions assume you are using Go 1.13+ or higher.

You can download the source code, compile the binary, and put it in your $GOPATH with go get.

go get -u github.com/GoogleCloudPlatform/docker-credential-gcr/v2

If $GOPATH/bin is in your system $PATH, this will also automatically install the compiled binary. You can confirm using which docker-credential-gcr and continue to the section on Configuration and Usage.

Alternatively, you can use go build to build the program. This creates a docker-credential-gcr executable.

cd $GOPATH/src/github.com/GoogleCloudPlatform/docker-credential-gcr
go build

Then, you can put that binary in your $PATH to make it visible to docker. For example, if /usr/bin is present in your system path:

sudo mv ./docker-credential-gcr /usr/bin/docker-credential-gcr

Configuration and Usage

  • Configure the Docker CLI to use docker-credential-gcr as a credential helper for the default set of GCR registries:

     docker-credential-gcr configure-docker

    To speed up docker builds, you can instead configure a minimal set of registries:

    docker-credential-gcr configure-docker --registries="eu.gcr.io, marketplace.gcr.io"
  • Log in to GCR (or don't! See the GCR Credentials section)

     docker-credential-gcr gcr-login
  • Use Docker!

     docker pull gcr.io/project-id/neato-container
  • Log out from GCR

     docker-credential-gcr gcr-logout

Manual Docker Client Configuration

Add a credHelpers entry in the Docker config file (usually ~/.docker/config.json on OSX and Linux, %USERPROFILE%\.docker\config.json on Windows) for each GCR registry that you care about. The key should be the domain of the registry (without the "https://") and the value should be the suffix of the credential helper binary (everything after "docker-credential-").

e.g. for `docker-credential-gcr`:
    {
      "auths" : {
            ...
      },
      "credHelpers": {
            "coolregistry.com": ... ,
            "gcr.io": "gcr",
            "asia.gcr.io": "gcr",
            ...
      },
      "HttpHeaders": ...
      "psFormat": ...
      "imagesFormat": ...
      "detachKeys": ...
    }
  

License

Apache 2.0. See LICENSE for more information.

docker-credential-gcr's People

Contributors

1azunna avatar brandonmichigangithub avatar dekkagaijin avatar dependabot[bot] avatar dlorenc avatar gridasov avatar grosskur avatar imjasonh avatar jamiekt avatar jonjohnsonjr avatar jvolkman avatar kmontg avatar kun-lu20 avatar lindsayismith avatar lisa avatar maxrossgoogle avatar mebaranov avatar megan-kuo avatar rafibarash avatar subserial avatar sudo-bmitch avatar vrothberg avatar yihanzhen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docker-credential-gcr's Issues

README.md lies!

Note: Google Kubernetes Engine blocks access to the GCE metadata server

In fact it doesn't see https://cloud.google.com/kubernetes-engine/docs/how-to/metadata-concealment

Note: Metadata concealment only protects access to kube-env and the VM's instance identity token; it does not protect access to the node's service account.

It might be clear to indicate that you would need to specify the correct scopes when creating the cluster

Crash when used by Kaniko in Google Cloud Build

I'm using docker-credential-gcr indirectly via kaniko in Google Cloud Build. When I use a recent version of Kaniko, which uses a recent version of this, I get the following crash:

...
Step #0: INFO[0148] Pushing layer us-central1-docker.pkg.dev/jgm-cloud-cxx/google-cloud-cpp-cloudbuild-docker/fedora-image/cache:c9a94ae6a3449e0c2d330d44632921f139be607646f008d7542890696f91e26f to cache now
Step #0: fatal error: unexpected signal during runtime execution
Step #0: [signal SIGSEGV: segmentation violation code=0x1 addr=0xe5 pc=0x7fd759f3dcb4]
Step #0:
Step #0: runtime stack:
Step #0: runtime.throw(0x7e0c4a, 0x2a)
Step #0:        /usr/local/go/src/runtime/panic.go:1116 +0x72
Step #0: runtime.sigpanic()
Step #0:        /usr/local/go/src/runtime/signal_unix.go:726 +0x4ac
Step #0:
Step #0: goroutine 1 [syscall]:
Step #0: runtime.cgocall(0x6a88c0, 0xc000085a30, 0xc000010038)
Step #0:        /usr/local/go/src/runtime/cgocall.go:133 +0x5b fp=0xc000085a00 sp=0xc0000859c8 pc=0x40563b
Step #0: os/user._Cfunc_mygetpwuid_r(0x0, 0xc0000b2ed0, 0xf2f070, 0x400, 0xc000010038, 0x7fd700000000)
Step #0:        _cgo_gotypes.go:175 +0x4d fp=0xc000085a30 sp=0xc000085a00 pc=0x68af8d
Step #0: os/user.lookupUnixUid.func1.1(0x0, 0xc0000b2ed0, 0xc000088dd0, 0xc000010038, 0xc000085ad0)
Step #0:        /usr/local/go/src/os/user/cgo_lookup_unix.go:103 +0xd0 fp=0xc000085a80 sp=0xc000085a30 pc=0x68bd30
Step #0: os/user.lookupUnixUid.func1(0x7987e0)
Step #0:        /usr/local/go/src/os/user/cgo_lookup_unix.go:103 +0x45 fp=0xc000085ab8 sp=0xc000085a80 pc=0x68bda5
Step #0: os/user.retryWithBuffer(0xc000088dd0, 0xc000085b90, 0x7fd75c9a1c00, 0x20300000000000)
Step #0:        /usr/local/go/src/os/user/cgo_lookup_unix.go:247 +0x3e fp=0xc000085b10 sp=0xc000085ab8 pc=0x68babe
Step #0: os/user.lookupUnixUid(0x0, 0x0, 0x0, 0x0)
Step #0:        /usr/local/go/src/os/user/cgo_lookup_unix.go:96 +0x132 fp=0xc000085bd8 sp=0xc000085b10 pc=0x68b3d2
Step #0: os/user.current(0xc000085c58, 0x4d40bc, 0xc0000b4ee0)
Step #0:        /usr/local/go/src/os/user/cgo_lookup_unix.go:49 +0x49 fp=0xc000085c18 sp=0xc000085bd8 pc=0x68b269
Step #0: os/user.Current.func1()
Step #0:        /usr/local/go/src/os/user/lookup.go:15 +0x25 fp=0xc000085c40 sp=0xc000085c18 pc=0x68bbe5
Step #0: sync.(*Once).doSlow(0xa09c40, 0x7ecf20)
Step #0:        /usr/local/go/src/sync/once.go:66 +0xec fp=0xc000085c90 sp=0xc000085c40 pc=0x474c8c
Step #0: sync.(*Once).Do(...)
Step #0:        /usr/local/go/src/sync/once.go:57
Step #0: os/user.Current(0x47705b, 0xa41360, 0xc0000b25d0)
Step #0:        /usr/local/go/src/os/user/lookup.go:15 +0x105 fp=0xc000085cc0 sp=0xc000085c90 pc=0x68ade5
Step #0: github.com/GoogleCloudPlatform/docker-credential-gcr/util.unixHomeDir(0x4d4700, 0xc0000b4ee0)
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/util/util.go:42 +0x25 fp=0xc000085cf0 sp=0xc000085cc0 pc=0x68e585
Step #0: github.com/GoogleCloudPlatform/docker-credential-gcr/util.SdkConfigPath(0x0, 0x0, 0x0, 0x0)
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/util/util.go:34 +0x26 fp=0xc000085d58 sp=0xc000085cf0 pc=0x68e466
Step #0: github.com/GoogleCloudPlatform/docker-credential-gcr/store.dockerCredentialPath(0x7fd7834cb108, 0xc000088dc0, 0x7fd7834d4328, 0x18)
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/store/store.go:215 +0x6d fp=0xc000085dc8 sp=0xc000085d58 pc=0x69186d
Step #0: github.com/GoogleCloudPlatform/docker-credential-gcr/store.DefaultGCRCredStore(...)
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/store/store.go:84
Step #0: github.com/GoogleCloudPlatform/docker-credential-gcr/cli.(*helperCmd).Execute(0xc00000e360, 0x8392e0, 0xc000016018, 0xc00009e3c0, 0x0, 0x0, 0x0, 0x0)
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/cli/dockerHelper.go:35 +0x35 fp=0xc000085e78 sp=0xc000085dc8 pc=0x6a6915
Step #0: github.com/GoogleCloudPlatform/docker-credential-gcr/vendor/github.com/google/subcommands.(*Commander).Execute(0xc000012100, 0x8392e0, 0xc000016018, 0x0, 0x0, 0x0, 0x39)
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/vendor/github.com/google/subcommands/subcommands.go:209 +0x30d fp=0xc000085f20 sp=0xc000085e78 pc=0x69252d
Step #0: github.com/GoogleCloudPlatform/docker-credential-gcr/vendor/github.com/google/subcommands.Execute(...)
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/vendor/github.com/google/subcommands/subcommands.go:492
Step #0: main.main()
Step #0:        /go/src/github.com/GoogleCloudPlatform/docker-credential-gcr/main.go:54 +0x63f fp=0xc000085f88 sp=0xc000085f20 pc=0x6a85bf
Step #0: runtime.main()
Step #0:        /usr/local/go/src/runtime/proc.go:204 +0x209 fp=0xc000085fe0 sp=0xc000085f88 pc=0x439c89
Step #0: runtime.goexit()
Step #0:        /usr/local/go/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc000085fe8 sp=0xc000085fe0 pc=0x46b841
Step #0: Collecting git+git://github.com/googleapis/python-storage@8cf6c62a96ba3fff7e5028d931231e28e5029f1c
Step #0:   Cloning git://github.com/googleapis/python-storage (to revision 8cf6c62a96ba3fff7e5028d931231e28e5029f1c) to /tmp/pip-req-build-2spex1i1
Step #0:   Running command git clone -q git://github.com/googleapis/python-storage /tmp/pip-req-build-2spex1i1
CANCELLED
ERROR: context canceled

I think the problem is in this code as described in GoogleContainerTools/kaniko#1604 (comment)

Update docker-credential-gcr version in the google cloud sdk install tarball

Even the latest available Cloud SDK version 310.0.0 installs old docker-credential-gcr version 1.5.0 from 2018:

gcloud version |egrep 'SDK|docker'
Google Cloud SDK 310.0.0
docker-credential-gcr 1.5.0

This old docker-credential-gcr version is causing lot of issues, forces users to set CLOUDSK_PYTHON variable to python2 or to remove ~/.docker/config.json.

Is it possible to update the GCR credential helper distributed in the cloud SDK with the latest 2.0.2 version?

I can't find the Google Cloud SDK git repo, so reporting the issue here.

Thanks in advance for fix!

Fix auth test issue

When Github Actions runs go vet with the newest version of go, it fails with call to (*T).Fatalf from a non-test goroutine (see error log).

Docker client version determination fails when Docker daemon is not available

Hi!

I have a situation where I'm building a Docker image containing this utility, all configured and raring to go, and naturally the container being built can't connect to a Docker daemon. In this situation, docker-credential-gcr configure-docker warns (but does not fail)

WARNING: Unable to determine Docker version: exit status 1
Configuring docker-credential-gcr as a registry-specific helper. This is only supported by Docker client versions 1.13+
/root/.docker/config.json configured to use this credential helper for GCR registries

It looks like util.dockerClientVersionStrings should not bail out even if the retcode of the docker version --format '{{.Client.Version}}' invocation is non-zero. The output of the command, when run in a shell, is as expected (the error is printed to stderr).

17.12.1-ce
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

SHA256 checksums don't match binary releases

Hello,

I tried downloading the binaries but was alerted that the checksums do not match what was listed on the release page.

For example if I execute:
curl -fsSL https://github.com/GoogleCloudPlatform/docker-credential-gcr/releases/download/v1.5.0/docker-credential-gcr_linux_amd64-1.5.0.tar.gz | openssl dgst -sha256

I get the SHA256:
ca8f0baa185b779162830986fbe7192ff15efebc0dba8153b0a9bce1100ca4ed

However, on the release page it reports the SHA256 as:
linux-amd64
1ca0b551fb36322c479c08f264e616cc693d4045531586a38b106192016b43ee

Are the sha's correct (or am I doing something wrong, perhaps using the wrong digest?)

Thanks

WARNING! Using --password via the CLI is insecure. Use --password-stdin.

It looks like docker changed the commandline option.

> gcloud --project xxx -- tag image eu.gcr.io/project/image:<ver>
ERROR: Docker CLI operation failed:

WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error saving credentials: error storing credentials - err: exit status 1, out: `docker-credential-gcr/helper: this operation is unsupported for GCR, please see docker-credential-gcr documentation for supported login methods. 'gcloud docker' is unnecessary when using docker-credential-gcr, use 'docker' instead.`

ERROR: (gcloud.docker) Docker login failed.

> docker --version
Docker version 17.09.0-ce, build afdb6d4

Release versions messed up?

Latest release at this time is v2.1.5

$ go install github.com/GoogleCloudPlatform/docker-credential-gcr@latest go: downloading github.com/GoogleCloudPlatform/docker-credential-gcr v2.0.5+incompatible

This is the hash for 2.1.5 version, but 1.5.1 is installed?
$ go install github.com/GoogleCloudPlatform/docker-credential-gcr@a14b07c go: downloading github.com/GoogleCloudPlatform/docker-credential-gcr v1.5.1-0.20220606170751-a14b07c61269

Misleading error message when no proper access for docker

Hi,

I was struggling yesterday with pulling an image from the GCR registry and I got the following error message multiple times:

Error response from daemon: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

However, this is not the case, because the problem was actually that my system was not able to run docker without sudo. And with sudo I was not able to use the gcloud CLI.

I used this stackoverflow as a solution: https://stackoverflow.com/questions/48957195/how-to-fix-docker-got-permission-denied-issue/48957722#48957722

Just sending this out here so people in the future won't have the same problem and you might want to change the error message since the problem is not in the authentication of Google Cloud.

Unable to authenticate to private Container Registry after using docker-credential-gcr on Container-Optimized OS 65-10323.97.0 stable

Hello,
After execution of docker-credential-gcr configure-docker with output as follows:
/home/<MY_USER>/.docker/config.json configured to use this credential helper for GCR registries.

When trying docker pull command (docker pull gcr.io/project/image) I get
Error response from daemon: repository gcr.io/project/image not found: does not exist or no pull access

When I check the container registry image is ready and build.

Here is the content of config.json

{
"auths": {},
"credHelpers": {
"asia.gcr.io": "gcr",
"eu.gcr.io": "gcr",
"gcr.io": "gcr",
"staging-k8s.gcr.io": "gcr",
"us.gcr.io": "gcr"
}
}

Feature Request: Provide an apt package for docker-credential-gcr

Currently we have to do a manual install of the gcloud SDK on GCP ubuntu VMS because gcloud is installed via apt, but provides no way of installing docker-credential-gcr without ripping out the whole install and reinstalling manually.

It seems odd that this is the one package omitted from apt compared to all of the other packages. It's also pretty painful to do all of that just to allow pulling of docker images from GCR on google produced images. I'm hoping there is either planned support for an apt docker-credential-gcr package sometime soon in the future, or some other solution without having to reinstall the sdk.

I'm open to ideas, and while I know we can produce an image with our manual reinstall, we are required to repave our machines every 30-90 days and don't have a good "image CI/CD" process in place to deal with something like this in time for production.

Thanks for taking the time to read this,
Cheers

Invert order of precedence for GCR token sources

Currently, the cred helper looks for tokens in magic places before looking for them in more manually configured places, e.g. GCR metadata > gcloud > private cred store. This should be the other way around, to decrease surprise factor.

Not thread safe?

While trying to speed something up, I noticed concurrent invocations can cause failures with this error:

docker-credential-gcr/helper: could not retrieve GCR's access token: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Repro:

for i in {1..100}; do (echo -n gcr.io | docker-credential-gcr get &); done

I suspect this is more likely an issue with https://github.com/golang/oauth2 (or how we're using it?).

Any ideas?

command not found: docker-credential-gcr

gcloud components install docker-credential-gcr

Your current Cloud SDK version is: 210.0.0
Installing components from version: 210.0.0

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ These components will be installed. โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚ Name โ”‚ Version โ”‚ Size โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚ Google Container Registry's Docker credential helper โ”‚ โ”‚ โ”‚
โ”‚ Google Container Registry's Docker credential helper โ”‚ 1.5.0 โ”‚ 1.8 MiB โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

For the latest full release notes, please visit:
https://cloud.google.com/sdk/release_notes

Do you want to continue (Y/n)? Y

โ•”โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•—
โ• โ• Creating update staging area โ•โ•ฃ
โ• โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•ฃ
โ• โ• Installing: Google Container Registry's Docker creden... โ•โ•ฃ
โ• โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•ฃ
โ• โ• Installing: Google Container Registry's Docker creden... โ•โ•ฃ
โ• โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•ฃ
โ• โ• Creating backup and activating new installation โ•โ•ฃ
โ•šโ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•

Performing post processing steps...done.

Update done!

$ docker-credential-gcr configure-docker
zsh: command not found: docker-credential-gcr

$ which gcloud
/usr/local/bin/gcloud

$ gcloud --version
Google Cloud SDK 210.0.0
bq 2.0.34
core 2018.07.27
docker-credential-gcr
gsutil 4.33

What am I missing?

Pulling image on a COS instance: WARNING: Unable to determine Docker version: exit status 1

The whole GCloud SDK's misleading and confusing docs is not worth our time but we are determined not to give in to your complexities. So on that negative note, you can ignore this ticket/complaint or try and convince us that you have built this tool for "human" developers.

The docs tell me to do this here are the outputs

me@att ~ $ docker-credential-gcr configure-docker

WARNING: Unable to determine Docker version: exit status 1
Configuring docker-credential-gcr as a registry-specific helper. This is only supported by Docker client versions 1.13+
/home/me/.docker/config.json configured to use this credential helper for GCR registries

me@att ~ $ docker -v

Docker version 17.03.2-ce, build f5ec1e2

me@att ~ $ docker-credential-gcr version

Google Container Registry Docker credential helper 1.4.2

me@att ~ $ cat /etc/os-release

BUILD_ID=10452.89.0
NAME="Container-Optimized OS"
KERNEL_COMMIT_ID=e2e439017d740b3fbe0f4f1a2bc63af84facf535
GOOGLE_CRASH_ID=Lakitu
VERSION_ID=66
BUG_REPORT_URL=https://crbug.com/new
PRETTY_NAME="Container-Optimized OS from Google"
VERSION=66
GOOGLE_METRICS_PRODUCT_ID=26
HOME_URL="https://cloud.google.com/compute/docs/containers/vm-image/"
ID=cos

BUT...as expected

me@att ~ docker pull --rm gcr.io/project/image:tag

docker: unauthorized: authentication required.

Unable to determine docker version error

~> docker-credential-gcr configure-docker
ERROR: Unable to determine Docker version: strconv.ParseInt: parsing "3'\n": invalid syntax

~> docker version
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 21:39:14 2016
OS/Arch: linux/amd64

Server:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 21:39:14 2016
OS/Arch: linux/amd64

Unable to push images in GCR - โ€œCaller does not have permission 'storage.buckets.create'.โ€

I'm using Standalone Docker credential helper authentication option to push docker images in GCR from local machine. Ran following command locally which created config.json file at following path - C:\Users\sunny.goel.docker

docker-credential-gcr configure-docker

Then I issued following command to get the credential for us.gcr.io region and noticed that secret returned in output doesn't match with auth attribute value for us.gcr.io region in config.json file. Shouldn't it match ideally ?

echo "https://us.gcr.io" | docker-credential-gcr get

Moreover, where can we find the caller information to assign the required roles (storage admin) ? I do see a number of service accounts but am not sure which one is used to create storage buckets ?

docker builds are slow, hanging on docker-credential-gcloud get

Docker builds when using gcloud credential helper take a long time to start.

Steps to reproduce:

I have a simple Dockerfile and no existing credentials configured.

โžœ  /tmp cat Dockerfile
FROM debian
RUN echo hello
โžœ  /tmp cat ~/.docker/config.json
cat: /Users/user/.docker/config.json: No such file or directory

I build it and it's very quick as one would expect.

โžœ  /tmp time docker build -t myimage:latest . --compress --no-cache
Sending build context to Docker daemon     486B
Step 1/2 : FROM debian
 ---> 874e27b628fd
Step 2/2 : RUN echo hello
 ---> Running in 57fcb43c274a
hello
 ---> d74e283f31eb
Removing intermediate container 57fcb43c274a
Successfully built d74e283f31eb
Successfully tagged myimage:latest
docker build -t myimage:latest . --compress --no-cache  0.02s user 0.05s system 3% cpu 1.655 total

I then use credential helper:

โžœ  /tmp gcloud alpha auth configure-docker
The following settings will be added to your Docker config file
located at [/Users/user/.docker/config.json]:
 {
  "credHelpers": {
    "gcr.io": "gcloud",
    "us.gcr.io": "gcloud",
    "eu.gcr.io": "gcloud",
    "asia.gcr.io": "gcloud",
    "l.gcr.io": "gcloud",
    "launcher.gcr.io": "gcloud",
    "us-mirror.gcr.io": "gcloud",
    "eu-mirror.gcr.io": "gcloud",
    "asia-mirror.gcr.io": "gcloud",
    "mirror.gcr.io": "gcloud"
  }
}

Do you want to continue (Y/n)?  y

Docker configuration file updated.
โžœ  /tmp cat ~/.docker/config.json
{
  "credHelpers": {
    "gcr.io": "gcloud",
    "us.gcr.io": "gcloud",
    "eu.gcr.io": "gcloud",
    "asia.gcr.io": "gcloud",
    "l.gcr.io": "gcloud",
    "launcher.gcr.io": "gcloud",
    "us-mirror.gcr.io": "gcloud",
    "eu-mirror.gcr.io": "gcloud",
    "asia-mirror.gcr.io": "gcloud",
    "mirror.gcr.io": "gcloud"
  }
}

Builds now take a loooong time start:

Sending build context to Docker daemon     486B
Step 1/2 : FROM debian
 ---> 874e27b628fd
Step 2/2 : RUN echo hello
 ---> Running in 8c2337496ef2
hello
 ---> d7fc72cb2fa1
Removing intermediate container 8c2337496ef2
Successfully built d7fc72cb2fa1
Successfully tagged myimage:latest
docker build -t myimage:latest . --compress --no-cache  42.60s user 22.68s system 26% cpu 4:04.47 total

I observe this when waiting for docker build:

~ ps auwx | grep gcloud
user           50991  20.6  0.2  4321284  31996 s009  S+    4:43pm   0:00.39 /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -S /Users/user/workspace/google-cloud-sdk/lib/gcloud.py auth docker-helper get
user           50980   0.0  0.0  4277552   1256 s009  S+    4:43pm   0:00.00 /bin/sh /Users/user/workspace/google-cloud-sdk/bin/docker-credential-gcloud get

I have yet to get much from tracing docker-credential-gcloud get but will update when I find more.

Output contains invalid Username for AR when installed using normal `go install`

When docker-credential-gcr is installed via e.g. go install github.com/GoogleCloudPlatform/docker-credential-gcr@62afb2723512fd6572c6300024e0c94f734b0ae3 it produces invalid output with a Username of _dcgcr__token which Artifact Registry doesn't accept.

This was discussed at #129 but this should remain an open issue until it is fixed: Specifically, building docker-credential-gcr using normal go install without setting any special flags should either fail to compile or it should produce a tool that actually works with Artifact Registry.

(I have never before seen a go tool that has a functional misbehavior like this when built using normal go install. ๐Ÿคฏ๐Ÿ˜ค This caused regclient/regclient#453 which was excruciatingly frustrating to diagnose.)

Wrong version using component install of Cloud sdk

I am trying to create my own image to use inside "Container optimized OS".

FROM google/cloud-sdk:alpine as builder1

RUN gcloud components install docker-credential-gcr --quiet
RUN gcloud components update
RUN docker-credential-gcr version





FROM docker/compose

COPY --from=builder1 /google-cloud-sdk/bin/* /usr/local/bin/
RUN docker-credential-gcr configure-docker
CMD docker-compose

I run into the problem that it always installs version 1.5.0 which does not let me add records for artifact registries.

Any idea how to install the correct version of docker-credential-gcr?

thanks in advance

"Requester pays" artifact buckets result in UserProjectMissing error code

Hi Team,

We're exploring whether GCR could be used with "requester pays" artifact buckets, so that users in other projects could pull from our public GCR repos, but pay for the requests and network charges.

To this end, we've enabled "requester pays" option on one of our artifact buckets (e.g. us.artifacts.<project-id>.appspot.com), and tried to pull from it to another project after authenticating with GCR:

$ docker-credential-gcr configure-docker
/home/<user>/.docker/config.json configured to use this credential helper for GCR registries

$ docker pull us.gcr.io/<project-id>/<image>:<tag>
<tag>: Pulling from <project-id>/<image>
f2b6b4884fc8: Pulling fs layer
...
error pulling image configuration: error parsing HTTP 400 response body: invalid character '<' looking for beginning of value: "<?xml version='1.0' encoding='UTF-8'?><Error><Code>UserProjectMissing</Code><Message>Bucket is a requester pays bucket but no user project provided.</Message></Error>"

This is the same error as when we try to run gsutil without -u option on that bucket. It seems like docker-credential-gcr could enable a similar option here - are there any plans or technical limitations on doing that?

EDIT: For an example implementation of it with Docker credential helper protocol, the project ID could be specified through

"Username": "oauthaccesstoken@project_id"

Then, if no @project_id is specified, GCR would use the regular bucket access mechanism.

Thank you!

gcloud docker cannot push to gcr.io anymore?

I already configured

~/work/src/k8s.io/test-infra/images/kubekins-e2e$ docker-credential-gcr configure-docker --overwrite
~/.docker/config.json successfully configured
Any previously stored credentials have been overwritten.
~/work/src/k8s.io/test-infra/images/kubekins-e2e$ docker-credential-gcr gcr-login
gcloud docker -- push gcr.io/<REDACTED>
ERROR: Docker CLI operation failed:

Error saving credentials: error storing credentials - err: exit status 1, out: `docker-credential-gcr/helper: this operation is unsupported for GCR, please see docker-credential-gcr documentation for supported login methods. 'gcloud docker' is unnecessary when using docker-credential-gcr, use 'docker' instead.`

ERROR: (gcloud.docker) Docker login failed.
make: *** [push] Error 1

while

docker push gcr.io/<REDACTED>

works perfectly fine

ssh -o ControlMaster=auto causing issue with docker-credential-gcr authentication?

(cross posted with superuser - sorry, not sure the best place to ask)

Via a python script, I am on a GCP VM trying to install docker, download docker-credential-gcr, and then authenticate+pull an image from gcr.

The commands are:

  1. sudo apt-get update && sudo apt-get install -y docker.io && sudo usermod -aG docker $USER
  2. (download docker-credential-gcr to ~/credential_getter/docker-credential-gcr)
  3. PATH=$PATH:~/credential_getter && docker-credential-gcr configure-docker && docker pull mycontainer_in_gcr

To submit each above command, I use the following:

ssh -i my.pem -o ConnectTimeout=120s -o StrictHostKeyChecking=no -o ControlMaster=auto -o ControlPath=/tmp/mypath/%C -o ControlPersist=10s -o IdentitiesOnly=yes -o ExitOnForwardFailure=yes -o ServerAliveInterval=5 -o ServerAliveCountMax=3 UNAME@IPADDRESS bash --login -c -i 

Where I use ControlMaster to reduce any lag between commands.

Commands 1) and 2) work fine, but with 3) I get strange behavior where the docker-credential-gcr prints to the screen as per normal saying it worked correctly, but then docker pull fails with a credential error. But then if I go into my terminal a few moments after 3) fails and paste the same ssh command as from 3), the command works correctly. Similarly, if I put a wait in the python script between 2) and 3) of more than the ControlMaster timeout, it works correctly.

If I send all three commands in the python script using:

ssh -i my.pem -o ConnectTimeout=120s -o StrictHostKeyChecking=no -o IdentitiesOnly=yes -o ExitOnForwardFailure=yes -o ServerAliveInterval=5 -o ServerAliveCountMax=3 UNAME@IPADDRESS bash --login -c -i COMMAND

(ControlMaster settings removed) it also works fine.

Any idea what could cause these different behaviors?

GKE serviceaccounts using workload identity auth frequently timeout

GKE serviceaccounts using workload identity auth frequently timeout when gke metadata server is under load.

see pull request: #72

and upstream fix googleapis/google-cloud-go@fbf2f51

 error getting credentials - err: exit status 1, out: `docker-credential-gcr/helper: could not retrieve GCR's access token: Get http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform: net/http: timeout awaiting response headers

Feature request: Add flag --config

Docker has a global --config flag documented here: https://docs.docker.com/engine/reference/commandline/cli/

Through this, you can define the location of config.json.

docker-credential-gcr configure-docker currently always generates the config file in ~/.docker. It would be nice to be able to modify this in the same way as in Docker.

I try to issue docker-credential-gcr configure-docker during the startup of a COS VM in GCP. It gives me an error that /root/.docker is a read-only filesystem, so I'd just like to put the file somewhere else.

Unable to use docker / docker-compose when auth fails

If my password changes or there is a network issue and google-cloud-sdk/bin/docker-credential-gcr get fails you will be unable to run any commands locally using docker or docker-compose that have nothing to do with gcloud.

This is a massive pain, that my docker commands have been completely hijacked and if there is an issue with gcloud, then nothing works.

I would expect for it to try and do gcloud stuff, but upon failure let me do what I wanted any way.

It does my head in seeing [1249] Failed to execute script docker-compose for a totally gcloud independent task.

bogus help for subcommands

Try to check whether my stored credentials are good.

docker-credential-gcr list
{"https://appengine.gcr.io":"oauth2accesstoken","https://asia.gcr.io":"oauth2accesstoken","https://eu.gcr.io":"oauth2accesstoken","https://gcr.io":"oauth2accesstoken","https://gcr.kubernetes.io":"oauth2accesstoken","https://us.gcr.io":"oauth2accesstoken"}
# looks good, now try one
docker-credential-gcr get https://eu.gcr.io
Usage: docker-credential-gcr <store|get|erase|list>
# okay, retry without arg
docker-credential-gcr get
<hangs, ctrl-c>
docker-credential-gcr help get
get: for the specified server, return the stored credentials via stdout
# so maybe tell people how to pass the 'specified server' if it is not obvious

Seems that Artifact Registry username has changed

Today I've spotted the following behavior for docker-credential-gcr and docker-credential-gcloud:

$ echo "https://europe-west2-docker.pkg.dev" | docker-credential-gcr get
{"ServerURL":"https://europe-west2-docker.pkg.dev","Username":"_dcgcr__token","Secret":"REDACTED"}

$ echo "https://europe-west2-docker.pkg.dev" | docker-credential-gcloud get
{"Username":"_dcgcloud_token","Secret":"REDACTED"}

Here what I've got using different credentials and docker registry v2 API provided by Artifact Registry:

Issue:

#: U="_dcgcr__token", does not work
$ curl -u "${U}:${TOKEN}" https://europe-west2-docker.pkg.dev/v2/privategoogleprojectid/test/repo/manifests/test
{"errors":[{"code":"UNAUTHORIZED","message":"No valid credential was supplied."}]}

OK:

#: U="_dcgcloud_token", works like expected
$ curl -u "${U}:${TOKEN}" https://europe-west2-docker.pkg.dev/v2/privategoogleprojectid/test/repo/manifests/test
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 739,
         "digest": "sha256:b27f378865b05a9ea042435b4a256f37aaf6a92c445532ae8e4704c750a9d2e3",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      }
   ]
}

Please provide ARM/ARM64 binaries

Please provide a build for ARM/ARM64 as well. These are needed for kaniko as well, currently the kaniko build uses the static build of the docker-credential-gcr for the image.

Does this support Identity Federation from external accounts?

Weird use case, but I'm trying to use docker-credential-gcr to authenticate docker client requests to us-docker.pkg.dev from an AWS instance that can generate Google credentials using Identity Federation.

From that documentation, I've used the command given (with the relevant variables replaced for my account):

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --output-file=FILEPATH \
    --aws

This generates a JSON file that I thought could be used as the GOOGLE_APPLICATION_CREDENTIALS key:

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
  "subject_token_type": "urn:ietf:params:aws:token-type:aws4_request",
  "token_url": "https://sts.googleapis.com/v1/token",
  "credential_source": {
    "environment_id": "aws1",
    "region_url": "http://169.254.169.254/latest/meta-data/placement/availability-zone",
    "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials",
    "regional_cred_verification_url": "https://sts.{region}.amazonaws.com?Action=GetCallerIdentity&Version=2011-06-15"
  },
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT_EMAIL:generateAccessToken"
}

When I set the GOOGLE_APPLICATION_CREDENTIALS environment variable to the location of this key file and try to pull an image I get this error

$ docker pull us-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME
Using default tag: latest
Error response from daemon: Get https://us-docker.pkg.dev/v2/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME/manifests/latest: denied: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/PROJECT_NAME/locations/us/repositories/REPOSITORY_NAME" (or it may not exist)

I'm assuming this is because docker-credential-gcr doesn't support "type": "external_account" JSON file keys:

$ echo us-docker.pkg.dev | docker-credential-gcr get
docker-credential-gcr/helper: could not retrieve GCR's access token: google: error getting credentials using GOOGLE_APPLICATION_CREDENTIALS environment variable: unknown credential type: "external_account"

Note I have been able to pull the above image on this AWS instance when I gave the helper a "type": "service_account" JSON file key for a service account downloaded from the console.

docker-credential-gcr seems to use golang.org/x/oauth2 version v0.0.0-20210817223510-7df4dd6e12ab, which is a high enough version to support identity federation to get the credentials. Am I doing something else wrong?

Unable to access Container Registry images despite running `docker-credential-gcr configure-docker` using docker-compose in Container Optimized OS

I am running Google's container optimized OS, with the docker-compose tool as documented by https://cloud.google.com/community/tutorials/docker-compose-on-container-optimized-os (docker-compose runs in a container, accessed by an alias)

I am getting the issue referenced here: docker/compose#4885, that is supposedly resolved.

I have already run the initialization command: docker-credential-gcr configure-docker

However, as per my comment there (docker/compose#4885 (comment)), I am unable to pull in container registry's images via the aforementioned docker-compose alias. docker pull gcr.io/PROJECT_ID/IMAGE works though.

Any help would be greatly appreciated.

Skopeo delete image failing - attempts deleting manifest before tag

Running command skopeo delete docker://gcr.io/<project>/<image>:<tag> --creds <cred>.

Fails with: {"errors":[{"code":"GOOGLE_MANIFEST_DANGLING_TAG","message":"Manifest is still referenced by tag: <tag>"}]} (400 Bad Request)"

It looks like it is attempting to delete the manifest first before removing the tags but this is not allowed by GCR. This may cause issues where it would require deleting all tags before a manifest can be removed. An associated issue with details can be found here: genuinetools/reg#136.

"Could not retrieve GCR's access token" when using Workload Identity

Hello! We're trying to push to GCR from a Gitlab CI/CD job running on GKE, using Workload Identity to provide the service account binding and giving the permissions to the corresponding IAM service account.

We can verify that the pod the job is running on is using the correct service account:

$ curl -H "Metadata-Flavor:Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
projects/eryx-varios/serviceAccounts/gitlab-runner-service-account@eryx-varios.iam.gserviceaccount.com

And that the service account does have the needed permissions (by providing the credentials explictly through a JSON key):

$ cat $GITLAB_SERVICE_ACCOUNT_JSON | docker login -u _json_key --password-stdin https://gcr.io/
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
$ docker push "$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG"
The push refers to repository [gcr.io/eryx-varios/eryx-app/ci-pipeline-gcloud]
(...)
# push succeeds

However when we use the docker-credential-gcr, docker fails to push (unauthorized):

$ docker-credential-gcr configure-docker
Configuring default registries....
WARNING: A long list of credential helpers may cause delays running 'docker build'.
We recommend passing the registry names via the --registries flag for the specific registries you are using
Adding config for all GCR registries.
/root/.docker/config.json configured to use this credential helper for GCR registries

$ docker push "$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG"
The push refers to repository [gcr.io/eryx-varios/eryx-app/ci-pipeline-gcloud]
(...)
unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

Trying to verify credentials also fails:

$ echo "https://gcr.io/" | docker-credential-gcr get
docker-credential-gcr/helper: could not retrieve GCR's access token: metadata: GCE metadata "instance/service-accounts/default/token?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform" not defined

Also, I don't know if this is relevant when using Workload Identity, but the VM on GKE has all access scopes enabled.

image

We would really like to avoid having to pass the JSON keys explicitly. Any help is appreciated.

Handle reauth / invalid_rapt errors more gracefully

My GCP org requires that I two-factor auth every day or so. The error message this cred helper emits when I need to go through the two-factor auth flow could be improved.

For example:

$ crane cp <img> gcr.io/<proj>/<img>
Error: failed to copy index: error getting credentials - err: exit status 1, out: `docker-credential-gcr/helper: could not retrieve GCR's access token: oauth2: cannot fetch token: 400 Bad Request
Response: {
  "error": "invalid_grant",
  "error_description": "reauth related error (invalid_rapt)",
  "error_uri": "https://support.google.com/a/answer/9368756",
  "error_subtype": "invalid_rapt"
}`
exit status 1

What this error message is actually saying is, I need to run docker-credential-gcr gcr-login, which pops up a browser window and refreshes auth so that this helper can use it.

I think it could be nice if this error case was detected at least to provide a better error message, and maybe even proactively invoke gcr-login to pop up the window instead of failing.

If this sounds good let me know and I can send a PR.

All v2.0.4 binaries have unexpected SHA256 checksums

I downloaded all builds from https://github.com/GoogleCloudPlatform/docker-credential-gcr/releases/tag/v2.0.4, and run sha256sum over them, and get:

$ sha256sum docker-credential-gcr_*
fb37bc90831807ccfda115fa8fbc27fd6564f085c5eb258962b3582b60e1ea71  docker-credential-gcr_darwin_amd64-2.0.4.tar.gz
170b3ce008d33caaf2347fb39b8ad23e6e3d9b00790304f531e6a37564806f41  docker-credential-gcr_darwin_arm64-2.0.4.tar.gz
932a07a4a77741801f2d4067dcf113be4e27f54c525f618f2dee2799a00765d6  docker-credential-gcr_linux_386-2.0.4.tar.gz
4fca8441c41802f4bcc4912672c55d4b1232decb90639f8a684d3b389e4e6e91  docker-credential-gcr_linux_amd64-2.0.4.tar.gz
9276eab0d6da985f01f5f0d6d00313c9a49768d4eb0112b5fb8b4fdda07d1f7d  docker-credential-gcr_linux_arm64-2.0.4.tar.gz
2a4e825b63c845d2e96d6d871926ef9c51a95a62a288b1e05b06019ededc7bd9  docker-credential-gcr_windows_386-2.0.4.tar.gz
fa8bd855ba23e7668b48381e8ac7ba2b42c311ae3c26b0ab662d5b212b25255d  docker-credential-gcr_windows_amd64-2.0.4.tar.gz

The expected checksums according to that page are:

docker-credential-gcr_darwin_amd64-2.0.4.tar.gz | 18ea62cf5335102e54081707b1098b419bf2c513141886862dc6eff3035b4a51
docker-credential-gcr_darwin_arm64-2.0.4.tar.gz | 56ef380ff4bf0647303ddba5ba526b5f47cd4e5504289b4d401532f8146dfe99
docker-credential-gcr_linux_386-2.0.4.tar.gz | 4828b961b720ce4c920e343649c1eb6f79f6476e829c85e37134d274a71d4648
docker-credential-gcr_linux_amd64-2.0.4.tar.gz | 716dd54138618abefe02e40197240864500f204ca58668295c49d8a72efbaae1
docker-credential-gcr_linux_arm64-2.0.4.tar.gz | 4a697b7040429844e71529aea6bc76afb53f52542e33c81f44143c1b33820cbb
docker-credential-gcr_windows_386-2.0.4.tar.gz | 913e4820caafae8f2b67a48a84174bcb9d6fbf3f2bf6e24ce6ddf949903f9d2b
docker-credential-gcr_windows_amd64-2.0.4.tar.gz | ee817ca49baf29284e7cac4f68dd33f2ad545591c622e16317e38bceb7b1d33f

I tested this on my local machine, and from a brand-new "Google Cloud Container Optimised Linux" instance, both show the same result.

Unable to install a pinned version using `go install`

/question

As developer trying to use docker-credential-gcr, I tried installing using go install

go install github.com/GoogleCloudPlatform/[email protected]

It results in the following error,

go: github.com/GoogleCloudPlatform/[email protected]: github.com/GoogleCloudPlatform/[email protected]: invalid version: module contains a go.mod file, so module path must match major version ("github.com/GoogleCloudPlatform/docker-credential-gcr/v2")

Based on the error I tried doing,

go install github.com/GoogleCloudPlatform/docker-credential-gcr/[email protected]

Which also results in same error as above.

If I do go install github.com/GoogleCloudPlatform/docker-credential-gcr@latest it works, but I need to pin to a version of the binary.

Any clues?

Check for either podman or docker in $PATH

Hi! I was following the tutorial in Artifact Registry, and wondering if the credential generated will be usable in podman, I was able to successfully to push images to AR without problems using podman, the only caveat was that during:

gcloud auth configure-docker us-east1-docker.pkg.dev
WARNING: `docker` not in system PATH.
`docker` and `docker-credential-gcloud` need to be in the same PATH in order to work correctly together.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.

It should check if either podman or docker is installed.

Thanks for the amazing work!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.