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
Remove ssh-keyscan from git credential initialization #2953
Conversation
/kind bug /hold needs tests |
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.
|
/hold cancel In order to test these changes I've updated an existing example and added a new one. It's actually kinda hard to write unit tests for our credential code that calls out to |
/test pull-tekton-pipeline-integration-tests |
1 similar comment
/test pull-tekton-pipeline-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.
Seems good to me. Should we have a "config" to disallow the "accept-new" (if the operator of tekton-pipelines wants to force users to provide ssh known_hosts) ?
Good thinking - I've created #2981 to capture the feature request. |
Should we include something about the change in behavior of ssh-keyscan in the release notes? |
Updated the release note to call it out. |
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
/cc @dlorenc @bobcatfish @afrittoli
ping; would be great to get this in as part of the 0.15 milestone. if that's not feasible I'll rollback the creds-init change and try again in 0.16. |
Before this change an SSH Git Secret without a known_hosts would cause Tekton to perform an ssh-keyscan of the remote host to get its public key. This would happen in the entrypoint of the Step which meant that every Step container would have to have a copy of ssh-keyscan. After this change the reponsibility for fetching missing host keys now falls on git-init, meaning that the Git PipelineResource and git-clone catalog task will fetch the missing keys at runtime. This is preferable because we can guarantee that the git-init image has ssh-keyscan in it.
The following is the coverage report on the affected files.
|
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlorenc 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 |
Changes
Fixes #2951
Before this change an SSH Git Secret without a known_hosts would cause Tekton to perform an ssh-keyscan of the remote host to get its public key. This would happen in the entrypoint of the Step which meant that every Step container would have to have a copy of ssh-keyscan.
After this change the reponsibility for fetching missing host keys now falls on git-init, meaning that the Git PipelineResource and git-clone catalog task will fetch the missing keys at runtime. This is preferable because we can guarantee that the git-init image has ssh in it. We no longer rely on
ssh-keyscan
at all and instead usessh
'sStrictHostKeyChecking=accept-new
option.Need tests/examples to:
known_hosts
does not result inssh-keyscan
erroring out a TaskRun.known_hosts
does result ingit-init
running withStrictHostKeyChecking=accept-new
known_hosts
doesnt result inStrictHostKeyChecking=accept-new
.Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
Release Notes