googlecloudplatform / docker-credential-gcr Goto Github PK
View Code? Open in Web Editor NEWA Docker credential helper for GCR users
Home Page: https://gcr.io
License: Apache License 2.0
A Docker credential helper for GCR users
Home Page: https://gcr.io
License: Apache License 2.0
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)
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
Docker switched to a new version scheme and it seems that it breaks the configure-docker
$ docker-credential-gcr configure-docker
ERROR: Docker client version 1.10+ required
$ docker --version
Docker version 17.03.0-ce, build 60ccb22
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.
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?
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
Please provide SHA256 checksums for your binary releases so it would then be possible to verify file integrity. Thanks. :)
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.
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.
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.
It's a bit weird that we have to commit the version number: #86
We should just set this with ldflags.
Are release artifacts available for v2.0.5?
404 Not Found for https://github.com/GoogleCloudPlatform/docker-credential-gcr/releases/download/v2.0.5/docker-credential-gcr_linux_amd64-2.0.5.tar.gz
Is there an option to extend the token time from one to two hours?
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?
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 ?
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
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
I had a ~/.docker/config.json
file with existing entries in the credHelpers
key, but running gcloud auth configure-docker
wiped those and replaced them with the gcloud
entries.
So it would be great to check the presence of a credHelpers
key and merge.
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"
}
}
Hello,
currently gcr aborts with ERROR: 'docker-credential-gcr' must exist on your PATH
With bazelbuild/rules_docker#2115 this will get obsolete for a bazel setup
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.
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
It would be really useful to be able to build docker-credential-gcr as a static binary to run in scratch images.
If it's just a matter of adding the flag to the Makefile, I could submit a PR for it!
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.
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!
Eliminates a disparity between it and Linux
~> 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
I couldn't build docker-credential-gcr because the subcommand (https://github.com/google/subcommands) was out of date.
When I checkout the subcommand's division 709b4d9d0533b488062e7cf8c94381c57b5e8763, I could build.
Please do something.
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
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
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.
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"
}
}
]
}
login still uses OOB and see https://developers.google.com/identity/protocols/oauth2/resources/oob-migration
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.
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!
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.)
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.
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).
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.
Some reasons:
docker build
s acquire a credential for each registry in the docker config. Fewer registries means faster docker build
s.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
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!
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?
/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?
(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:
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?
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?
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.
We would really like to avoid having to pass the JSON keys explicitly. Any help is appreciated.
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.