Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kaniko requires authentication for base images that are in gcr.io #966

Open
samos123 opened this issue Jan 13, 2020 · 1 comment
Open

kaniko requires authentication for base images that are in gcr.io #966

samos123 opened this issue Jan 13, 2020 · 1 comment
Labels
area/behavior all bugs related to kaniko behavior like running in as root kind/bug Something isn't working priority/p3 agreed that this would be good to have, but no one is available at the moment.

Comments

@samos123
Copy link
Contributor

samos123 commented Jan 13, 2020

Actual behavior
I tried to use --tarPath where the base image is in gcr.io which will cause it to try to authenticate to gcr.io even for public images.
Update: the issue is more widespread. It's an issue also when you're not using --tarPath, for example if you were using a local registry and are not authenticated with gcr.

Expected behavior
base images in gcr.io shouldn't need authentication

To Reproduce
Steps to reproduce the behavior:

  1. Run the following and watch it fail:
cd GoogleContainerTools/kaniko
docker run \                                      
  -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest \
  --dockerfile=/workspace/integration/dockerfiles/Dockerfile_test_cmd --context=dir:///workspace/integration \
--no-push --tarPath /workspace/test_add.tar --force
  1. This will also fail if you have a docker registry running in localhost:5000
docker run \                          
 --net=host -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest \
  --dockerfile=/workspace/integration/dockerfiles/Dockerfile_test_add --context=dir:///workspace/integration \
--destination=localhost:5000/kaniko-test --force
INFO[0000] Resolved base name gcr.io/google-appengine/debian9@sha256:1d6a9a6d106bd795098f60f4abb7083626354fa6735e81743c7f8cfca11259f0 to gcr.io/google-appengine/debian9@sha256:1d6a9a6d106bd795098f60f4abb7083626354fa6735e81743c7f8cfca11259f0
INFO[0000] Using dockerignore file: /workspace/integration/.dockerignore
INFO[0000] Resolved base name gcr.io/google-appengine/debian9@sha256:1d6a9a6d106bd795098f60f4abb7083626354fa6735e81743c7f8cfca11259f0 to gcr.io/google-appengine/debian9@sha256:1d6a9a6d106bd795098f60f4abb7083626354fa6735e81743c7f8cfca11259f0
INFO[0000] Image gcr.io/google-appengine/debian9@sha256:1d6a9a6d106bd795098f60f4abb7083626354fa6735e81743c7f8cfca11259f0 not found in cache
INFO[0000] Retrieving image manifest gcr.io/google-appengine/debian9@sha256:1d6a9a6d106bd795098f60f4abb7083626354fa6735e81743c7f8cfca11259f0
error building image: Get https://gcr.io/v2/token?scope=repository%3Agoogle-appengine%2Fdebian9%3Apull&service=gcr.io: invoking docker-credential-gcr: exit status 1; output: 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.

Additional Information

Triage Notes for the Maintainers

Description Yes/No
Please check if this a new feature you are proposing
Please check if the build works in docker but not in kaniko
Please check if this error is seen when you use --cache flag
Please check if your dockerfile is a multistage dockerfile
@samos123 samos123 changed the title Desitination using --tarPath doesn't work if base image is in gcr.io kaniko requires authentication for base images that are in gcr.io Jan 13, 2020
@tejal29 tejal29 added area/behavior all bugs related to kaniko behavior like running in as root kind/bug Something isn't working labels Jan 17, 2020
samos123 added a commit to samos123/kaniko that referenced this issue Jan 19, 2020
- Change integration tests to use docker hub instead of GCR due to bug
in library that requires authentication with gcr.io even for public
images. See GoogleContainerTools#966 for bug tracking this.
- Make uploading to GCS bucket configurable through a flag --uploadToGCS
- Utilize a locally deployed docker registry in travis CI to remove
dependency of needing to authenticate with GCP. This requires host
networking such that we can access the registry on localhost:5000
- Use the commit that's being tested for `TestGitBuildcontext`
- Remove duplicate GitBuildContext case that's now covered by default in
travis CI.
samos123 added a commit to samos123/kaniko that referenced this issue Jan 20, 2020
- Change integration tests to use docker hub instead of GCR due to bug
in library that requires authentication with gcr.io even for public
images. See GoogleContainerTools#966 for bug tracking this.
- Make uploading to GCS bucket configurable through a flag --uploadToGCS
- Utilize a locally deployed docker registry in travis CI to remove
dependency of needing to authenticate with GCP. This requires host
networking such that we can access the registry on localhost:5000
- Use the commit that's being tested for `TestGitBuildcontext`
- Remove duplicate GitBuildContext case that's now covered by default in
travis CI.
@tejal29 tejal29 added the priority/p3 agreed that this would be good to have, but no one is available at the moment. label Jan 22, 2020
@filesnate
Copy link
Contributor

See #1125 which may be related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/behavior all bugs related to kaniko behavior like running in as root kind/bug Something isn't working priority/p3 agreed that this would be good to have, but no one is available at the moment.
Projects
None yet
Development

No branches or pull requests

3 participants