Updated ServiceAccount.yaml for Docker auth

[ashugcet]

Changes

ServiceAccount.yaml needs K8s secret parameter as "imagePullSecrets" not "Secrets" as mentioned in the doc.

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
• Has Tests included if any functionality added or changed
• pre-commit Passed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

[linux-foundation-easycla]

• ✅login: ashugcet / (6977d66)

The committers listed above are authorized under a signed CLA.

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign vdemeester after the PR has been reviewed.
You can assign the PR to them by writing /assign @vdemeester in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tekton-robot]

Hi @ashugcet. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tekton-robot]

The following Tekton test failed:

Test name	Commit	Details	Required	Rerun command
check-pr-has-kind-label	6977d66	link	true	/test check-pr-has-kind-label

[ashugcet]

PR: Updated ServiceAccount.yaml for Docker auth #7736 will solve the issue mentioned below:
#4603

I faced this issue in my test and it got resolved with the changes which I have submitted in the above PR.

[vdemeester]

@ashugcet Thanks for the PR, but it is not accurate though. This documentation is about how to make the tekton "helpers" (entrypoint) put the right "docker" auth ($HOME/.docker/config.json or $DOCKER_CONFIG) content in the right place, in the pod that will need it. And, for this, the tekton code looks for the secrets attached to the ServiceAccount and not the imagePullSecrets. Usually, imagePullSecret on a ServiceAccount is to allow the node to pull an image that needs some credentials to access it ; which is different, and not documented here (I don't remember where / if it's documented though).

[ashugcet]

@ashugcet Thanks for the PR, but it is not accurate though. This documentation is about how to make the tekton "helpers" (entrypoint) put the right "docker" auth ($HOME/.docker/config.json or $DOCKER_CONFIG) content in the right place, in the pod that will need it. And, for this, the tekton code looks for the secrets attached to the ServiceAccount and not the imagePullSecrets. Usually, imagePullSecret on a ServiceAccount is to allow the node to pull an image that needs some credentials to access it ; which is different, and not documented here (I don't remember where / if it's documented though).

But this doc also says that when we associate this ServiceAccount with either PipelineRun or TaskRun it will work, which it doesn't in cases where the task is to deploy a Docker image from private registry using the secret. I was victim of this confusion and before me also few people have wasted time. May be this should be at least mentioned somewhere so that people do not struggle with starting with Tekton.

The doc also says: "When the Steps execute, Tekton uses those credentials to access the target Docker registry." Which is not correct.

[vdemeester]

The doc also says: "When the Steps execute, Tekton uses those credentials to access the target Docker registry." Which is not correct.

Well, we need to define "execute". The imagePullSecret is required when the Pod is scheduled (just after being created). When the Pod (or the container/step) execute, the image(s) is (are) already pulled on the Node, so execute in that sense (and in the doc), is when the process in the Pod is starting (or going to start).

But I do agree, that documentation needs a bit more clarification, I created #7737 👼🏼.

But as is, that pull-request is not correct as it doesn't work in the example it gives (with those changes, if you want a $HOME/.docker/config.json with the content of the secret, it won't be the case, where it was before the PR).

[ashugcet]

The doc also says: "When the Steps execute, Tekton uses those credentials to access the target Docker registry." Which is not correct.

Well, we need to define "execute". The imagePullSecret is required when the Pod is scheduled (just after being created). When the Pod (or the container/step) execute, the image(s) is (are) already pulled on the Node, so execute in that sense (and in the doc), is when the process in the Pod is starting (or going to start).

But I do agree, that documentation needs a bit more clarification, I created #7737 👼🏼.

But as is, that pull-request is not correct as it doesn't work in the example it gives (with those changes, if you want a $HOME/.docker/config.json with the content of the secret, it won't be the case, where it was before the PR).

Understood. Thanks for the clarification.