Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Use podTemplate ImagePullSecrets for Entrypoint Image Lookup #4496
Use podTemplate ImagePullSecrets for Entrypoint Image Lookup #4496
Changes from all commits
af80197
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another useful test I thought of -
[]corev1.LocalObjectReference{badsecret, goodsecret}
e.g. test that we iterate through the chain properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we expecting err or not for this case? I tried with this case, but
k8schain.New()
will return errerror creating k8schain: secrets "wrong secret" not found
. This is a little bit anti my intuition.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good to know (also a good reason to add tests for these cases)!
I think it's reasonable to error if the secret doesn't exist. But if the bad secret exists but just isn't the right password, then I would assume the next secret would be tried (otherwise there isn't really a reason to provide multiple secrets).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I see. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After taking a look at the go-containerregistry latest code, I found out that the function use a map to store all the auths, where
k
is the remote host and value is encoded auth. So for this test case. The 2 secrets have the same host, the first come auth will be stored in keychain and others will be ignored.Related code see here:
https://github.com/google/go-containerregistry/blob/9c35968ef47ec2e4a14a82ea72167f8655c7c853/pkg/authn/kubernetes/keychain.go#L106-L133
docker/config.json
, the file is written only when user has successfully login. So it is of low possibility that the secret is bad or incorrect. (e.g. user manually manipulates the file later.)What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! I prefer to keep it and document it in the comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
emmm, it may need more restructuring of the code, I will remove it for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, this isn't technically true. You can edit that file to contain any username/password, and many tools implement "login" simply be editing that file without validating that the username/password is correct at all.
If there are improvements we can make to that keychain, especially if it helps Tekton users, we should consider them. I'll happily approve :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see, thank you! I thought the login will do authentication to make sure the auth is valid.
So this is an interesting case and I'm not sure which makes more sense (Sorry again I'm still new to this but I'm willing to learn more 😄 ).
From the following code, Say if I have 2 secrets with the same remote registry, but one is incorrect and another is correct. If the bad secret comes first then the correct one will be ignored and not stored in map. Only bad secret will be written into header and sent to server.
This is just what I see from the test case, what I cannot see is what will be the real case, will this
{bad secret, correct secret}
happen in real use cases? If so, I think some work should be done from thego-containerregistry
repo. If not, then I think there's nothing to worry about.@wlynch @imjasonh
https://github.com/google/go-containerregistry/blob/9c35968ef47ec2e4a14a82ea72167f8655c7c853/pkg/authn/kubernetes/keychain.go#L106
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, in that case, today, go-containerregistry will select the first matching secret and use it, not knowing whether it's bad or good. It will only be able to tell whether one is "bad" or "good" by using it to try to auth to the registry, and by that time it's already dropped the old possible alternatives, and will just fail with the "bad" credentials.
This is a bit of a known gap in this keychain logic, and we have some ideas about how to fix it, but it's not really something we see come up much in practice today, so it hasn't been a top priority.