-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Conversation
This comment has been minimized.
This comment has been minimized.
1 similar comment
/test pull-tekton-pipeline-integration-tests |
b4a2ac5
to
5c0891e
Compare
/assign @wlynch |
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.
Impl looks reasonable - though there aren't really tests for the remote behavior. :(
The kubeclient should be easy enough to fake out (https://pkg.go.dev/k8s.io/client-go/kubernetes/fake), but I'm not sure off the top of my head how we would fake out the remote containerregistry call.
pipeline/pkg/remote/oci/resolver_test.go
Lines 263 to 268 in 4186dc9
ref, err := test.CreateImageWithAnnotations(fmt.Sprintf("%s/testociresolve/%s", u.Host, tc.name), tc.mapper, tc.objs...) | |
if err != nil { | |
t.Fatalf("could not push image: %#v", err) | |
} | |
resolver := oci.NewResolver(ref, authn.DefaultKeychain) |
/cc @imjasonh In case you have any other ideas.
The following is the coverage report on the affected files.
|
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.
Looks good, and thanks for adding tests! Just a few small comments, otherwise lgtm.
docs/podtemplates.md
Outdated
@@ -95,6 +95,40 @@ Pod templates support fields listed in the table below. | |||
</tbody> | |||
</table> | |||
|
|||
## Use <code>imagePullSecrets</code> to lookup entrypoint | |||
|
|||
If no command is configured in <code>task</code> and <code>imagePullSecrets</code> is configured in <code>podTemplate</code>, the Tekton Controller will look up the entrypoint of image with <code>imagePullSecrets</code>. If the Tekton controller's service account is not granted the access to secrets in different namespace. You need to grant the access via RoleBinding: |
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.
Is this necessary, since the SA already has cluster-wide read access to secrets?
If this is meant to document what's necessary for folks that explicitly disable Tekton's cluster-wide secrets access, I think we can just assume that users sophisticated/paranoid enough to do that are able to figure out what else they'd need to do to re-enable it for required 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.
This is in case the access may be removed in the future, Billy told me that it might be removed so it would be better to document it.
fakeclient "k8s.io/client-go/kubernetes/fake" | ||
) | ||
|
||
func TestGet(t *testing.T) { |
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.
I'm always glad to have more tests, and this should ensure the code is at least exercised, but it doesn't currently really ensure that the specified imagePullSecret is used when making requests to the registry. I think it's worth keeping, but maybe we should document its limitations so we don't get a false sense of security here.
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.
I have been working on trying to address. Please let me know if the latest change makes sense or not. 😄
Thanks!
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
a38f423
to
54b36e7
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
username: "", | ||
password: "", | ||
}, | ||
} { |
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.
Might also be worth testing a secret that exists but isn't authorized, no secret (in case empty string is different than nil), and a secret that does exist at all.
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-alpha-integration-tests |
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 change looks great! Thanks for working on this. 👍
basicSecret: generateSecret(u.Host, username, password), | ||
imagePullSecrets: []corev1.LocalObjectReference{}, | ||
wantErr: true, | ||
}} { |
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.
The secret is created from .docker/config.json, the file is written only when user has successfully login.
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 :)
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
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.
/lgtm
🎉
8fca8ee
to
af80197
Compare
The following is the coverage report on the affected files.
|
Sorry the squash cleared the review, may you review it again. 😄 |
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.
/lgtm
/assign @bobcatfish |
/lgtm |
@Yongxuanzhang please add the release notes. This PR is fixing an issue where entrypoint image lookup did not have access to or ignored the secrets specified in the podTemplate. The users can opt in by creating appropriate role binding to allow image lookup using these secrets. |
Hi, @pritidesai Thank you for reminding me of the release note! |
Thanks! /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: imjasonh, wlynch The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes #3799 |
Changes
This PR aims at closing the #3799.
Prior to this commit, we don't use
imagePullSecrets
frompodTemplate
to fetch secrets and resolve entrypoints for images. This commit aims at passing theimagePullSecrets
tok8schain
so it can append theimagePullSecrets
into key chain.This PR also adds unit test for
EntrypointCache.get()
implementation and improves the test coverage from 0% to 58%.Note that the controller's service account has the access to secrets. If it is deprecated or the access is removed, the Rolebinding is required for users to avoid errors when calling
k8schain
. See comments in #3799.Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes