Expected Behavior
Following the README results in successful clones of git repos.
Actual Behavior
/ko-app/git-init, git clone, and ssh all fail with the error 'No user exists for uid 65532'.
Steps to Reproduce the Problem
- Install version 0.10 of
git-clone using kubectl apply -f https://api.hub.tekton.dev/v1/resource/tekton/task/git-clone/0.10/raw
- Follow the README to set up a
git-clone task with credentials provided either via the ssh-directory or provided via a k8s service account.
- Run the
git-clone task
- The task will fail
Additional Info
This is a regression. For example, version 0.9 successfully clones over ssh.
There are a few things that combine to make it hard or impossible to get SSH to work with the default image:
-
(1) The image runs with runAsUser: 65532, which does not have a username associated with it.
-
(2) The base image (which I believe is a ko image) provides an /etc/passwd entry for the nobody user with uid 65534 and home directory /nonexistent. But that's not the user git-clone runs as.
-
(3) OpenSSH calls getpwuid to find the user based on their UID here. This hard-coded call is why the task fails.
-
(4) You can't add a username or modify the existing user because git-clone sets runAsNonRoot: true in the securityContext. Also the standard utilities like useradd and usermod do not exist on the container.
-
(5) You can't modify the task to run as the nobody user, because then SSH looks for the SSH config in /nonexistent despite git-clone setting the HOME environment variable to /home/git. You can tell SSH to look for a config in $HOME using ssh -F $HOME/.ssh/config, but git-clone doesn`t provide way to set a custom SSH command.
You can run git-clone as root by simply kubectl editing or patching the task and removing the security context. But that is not ideal.
Two recommendations:
-
(r1) since the run environment has changed a lot since the task was designed, communicate a unified approach running as non-root. If it's okay to have a UID and set $HOME, is it okay to have a real user? It's hard to tell as a user which parts of the interface are deliberate security decisions and which parts are working around limitations of the base image.
-
(r2) add an example and test for git clone over SSH since this will generally be an edge case and it will help users understand how to set up their own environments
Expected Behavior
Following the README results in successful clones of git repos.
Actual Behavior
/ko-app/git-init,git clone, andsshall fail with the error 'No user exists for uid 65532'.Steps to Reproduce the Problem
git-cloneusingkubectl apply -f https://api.hub.tekton.dev/v1/resource/tekton/task/git-clone/0.10/rawgit-clonetask with credentials provided either via thessh-directoryor provided via a k8s service account.git-clonetaskAdditional Info
This is a regression. For example, version 0.9 successfully clones over ssh.
There are a few things that combine to make it hard or impossible to get SSH to work with the default image:
(1) The image runs with
runAsUser: 65532, which does not have a username associated with it.(2) The base image (which I believe is a
koimage) provides an/etc/passwdentry for thenobodyuser withuid65534 and home directory/nonexistent. But that's not the usergit-cloneruns as.(3) OpenSSH calls getpwuid to find the user based on their UID here. This hard-coded call is why the task fails.
(4) You can't add a username or modify the existing user because
git-clonesetsrunAsNonRoot: truein thesecurityContext. Also the standard utilities likeuseraddandusermoddo not exist on the container.(5) You can't modify the task to run as the
nobodyuser, because then SSH looks for the SSH config in/nonexistentdespitegit-clonesetting theHOMEenvironment variable to/home/git. You can tell SSH to look for a config in$HOMEusingssh -F $HOME/.ssh/config, butgit-clonedoesn`t provide way to set a custom SSH command.You can run
git-cloneas root by simplykubectl editing or patching thetaskand removing the security context. But that is not ideal.Two recommendations:
(r1) since the run environment has changed a lot since the task was designed, communicate a unified approach running as non-root. If it's okay to have a UID and set
$HOME, is it okay to have a real user? It's hard to tell as a user which parts of the interface are deliberate security decisions and which parts are working around limitations of the base image.(r2) add an example and test for git clone over SSH since this will generally be an edge case and it will help users understand how to set up their own environments