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

'UNAUTHORIZED' when verifying repo write access for images, but pushing builder image works fine #1712

Open
Milkshak3s opened this issue Sep 17, 2024 · 3 comments

Comments

@Milkshak3s
Copy link

I'm running into an issue where supplying private repository credentials to an Image leads to UNAUTHORIZED , but supplying those same exact credentials in the same secret for a Builder leads to the builder image successfully being pushed to the repository.

Image build logs:

 Build reason(s): CONFIG

 CONFIG:

 	resources: {}

 	- source: {}

 	+ source:

 	+   git:

 	+     revision: 3be289517d320a47bb8f359acc1d1daf0829ed0b

 	+     url: https://github.com/spring-projects/spring-petclinic

 Loading registry credentials from service account secrets

 Loading secret for "harbor.example.com/project" from secret "kpack-reg-creds-2" at location "/var/build-secrets/kpack-reg-creds-2"

 Loading cluster credential helpers

 Error verifying write access to "harbor.example.com/project/test": UNAUTHORIZED

Builder exists:

milkshak3s@ubuntu:~/kpack$ kp builder list -n kpack-test
NAME               READY    STACK                         IMAGE
default-builder    true     io.buildpacks.stacks.jammy    harbor.example.com/project/builder:builder-kpack-test-default-builder@sha256:d8044d1e15edbb8f2e6619e401e5bfc225c9269b8e786586cc72b199b32119d2
@Milkshak3s
Copy link
Author

My workaround has been to use a secret of type type: kubernetes.io/basic-auth rather than type: kubernetes.io/dockerconfigjson

@chenbh
Copy link
Contributor

chenbh commented Oct 18, 2024

Just for sanity's sake:

  1. The project test exists in harbor? In your example the Builder is pushing to builder project but the Image is pushing to test
  2. Is your workaround that you switched the data from username/password to .dockerconfig.json, or did you use the same data and just changed the type?

@tomkennedy513
Copy link
Collaborator

The secret seems suspect to me. When the secret is loaded during prepare it should say harbor.example.com not harbor.example.com/project since the credential matching works on domains. Can you validate the secret is configured for harbor.example.com only?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants