-
Notifications
You must be signed in to change notification settings - Fork 542
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
Fix Azure Container Registry authentication #1256
Conversation
I will try to fix the corporate CLA on Monday. |
Codecov Report
@@ Coverage Diff @@
## main #1256 +/- ##
==========================================
- Coverage 73.77% 73.74% -0.03%
==========================================
Files 111 111
Lines 8285 8289 +4
==========================================
+ Hits 6112 6113 +1
- Misses 1571 1573 +2
- Partials 602 603 +1
Continue to review full report at Codecov.
|
Thanks so much for your investigation into why this was broken, and for your thorough description, and for your PR. If we're ever in the same place and you'd like a beer, it's on me. 🍻 I think I'd be okay changing
(...and if that's practically how cred helpers in the wild work today) If that's the case then we'd only need to change What do you think? |
@imjasonh hi! 😊 No problem at all! Just fun 🎉 Beer sounds nice 🍻 I agree with you and will update the PR. 😊👍 |
This will return an IdentityToken instead of a password if the username is set to '<token>'. This is based on the documentation from Docker as well as the code in go-containerregistry that only will use OAuth if there's an IdentityToken present. Reference to the documentation: https://docs.docker.com/engine/reference/commandline/login/#credential-helper-protocol
e4c3706
to
2b443e7
Compare
Hey, so I think if we change this line to pass https://github.com/google/go-containerregistry/blob/main/pkg/authn/keychain.go#L157 I think all parts of this bug can be fixed inside our own code 🎉 |
@imjasonh nice catch! Do you want it in a separate PR or is it OK in this one? |
I'm fine to include it in this one. |
This will ensure helpers don't need to strip path and query or validate if the scheme is present in the string or not.
@imjasonh added! I've validated that it's working in my environment (only Azure though). |
We should have signed the corporate CLA from our side today, but I think it needs to be counter signed by Google and we're waiting for that right now. I can't see anything about it when logged in at least. I'll check back tomorrow and see if there's any updates. |
If it's okay, I've opened #1265 which adds on this PR and includes unit tests. And since I'm already cleared for the CLA, we can merge it without waiting for Google. I'd like to get this included in cosign soon so they can cut a v1.5.1 with this fix for Azure users such as yourself. (If you'd prefer to wait for the Google CLA, please let me know and I'll close mine, I don't mean to step on any toes) Thanks again for your excellent work, and I look forward to working with you again more in the future! 👍 |
Go for it! 🎉 Just close this one when you've merged yours 😊 |
Fixes #1255
I'm not sure if this is the best or preferred way of handling this, another way may be to add a check to
NewKeychainFromHelper()
that checks if the username is<token>
and addsIdentityToken
to theAuthConfig{}
.Any and all feedback is welcome and if you see that I've missed something obvious and that's why I've done this, please point it out and I'll fix the issue where it's located.