Skip to content
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

Steps can't use creds-init credentials when their UID is different from creds-init UID and disable-home-env-overwrite=true #2524

Closed
ghost opened this issue May 1, 2020 · 2 comments · Fixed by #2671
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@ghost
Copy link

ghost commented May 1, 2020

Expected Behavior

When a Step has its own non-root UID which is different from creds-init any credentials should still be usable by that Step.

Actual Behavior

The Step will fail to utilize credentials.

When disable-home-env-overwrite is "true" the Step's entrypointer tries to copy credentials out of /tekton/creds into $HOME. But the UID of the Step is different from creds-init. The files inside of /tekton/creds are owned by whatever user creds-init ran as. The Step is disallowed from reading those files as it tries to copy them out.

Steps to Reproduce the Problem

Set disable-home-env-overwrite feature flag to "true". Redeploy tekton. Apply taskrun:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: test
spec:
  taskSpec:
    steps:
    - name: check-dirs
      image: ubuntu
      env:
      - name: HOME
        value: /myhome
      securityContext:
        runAsUser: 1111
        runAsGroup: 2222
      script: |
        id
        echo $HOME
        ls -lahR /tekton/creds

See errors in step logs. Example: unsuccessful cred copy: ".ssh" from "/tekton/creds" to "/workspace": unable to open source: open /tekton/creds/.ssh/known_hosts: permission denied

Additional Info

Originally discussed here: #2165

@ghost ghost added the kind/bug Categorizes issue or PR as related to a bug. label May 1, 2020
@ghost
Copy link
Author

ghost commented May 8, 2020

Here's a slightly more in-depth illustration of the problem:

[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".docker" from "/tekton/creds" to "/myhome": unable to create destination directory: mkdir /myhome: permission denied
[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".gitconfig" from "/tekton/creds" to "/myhome": unable to open source: open /tekton/creds/.gitconfig: permission denied
[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".git-credentials" from "/tekton/creds" to "/myhome": unable to open source: open /tekton/creds/.git-credentials: permission denied
[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".ssh" from "/tekton/creds" to "/myhome": unable to create destination directory: mkdir /myhome: permission denied
[check-dirs] + id
[check-dirs] uid=1111 gid=2222 groups=2222
[check-dirs] /myhome
[check-dirs] + echo /myhome
[check-dirs] + ls -lahR /tekton/creds
[check-dirs] /tekton/creds:
[check-dirs] total 8.0K
[check-dirs] drwxrwxrwt 4 root root  120 May  8 16:33 .
[check-dirs] drwxr-xr-x 8 root root 4.0K May  8 16:33 ..
[check-dirs] drwxr-xr-x 2 root root   60 May  8 16:33 .docker
[check-dirs] -rw------- 1 root root    0 May  8 16:33 .git-credentials
[check-dirs] -rw------- 1 root root   29 May  8 16:33 .gitconfig
[check-dirs] drwxr-xr-x 2 root root  100 May  8 16:33 .ssh
[check-dirs]
[check-dirs] /tekton/creds/.docker:
[check-dirs] total 4.0K
[check-dirs] drwxr-xr-x 2 root root  60 May  8 16:33 .
[check-dirs] drwxrwxrwt 4 root root 120 May  8 16:33 ..
[check-dirs] -rw------- 1 root root  12 May  8 16:33 config.json
[check-dirs]
[check-dirs] /tekton/creds/.ssh:
[check-dirs] total 12K
[check-dirs] drwxr-xr-x 2 root root 100 May  8 16:33 .
[check-dirs] drwxrwxrwt 4 root root 120 May  8 16:33 ..
[check-dirs] -rw------- 1 root root 110 May  8 16:33 config
[check-dirs] -rw------- 1 root root  23 May  8 16:33 id_fake-ssh-directory
[check-dirs] -rw------- 1 root root  28 May  8 16:33 known_hosts

creds-init has written credentials to the /tekton/creds directory as the root user. So the files it wrote are owned by root/root. My Step runs as user 1111 in group 2222. So my Step is not able to open those creds for reading.

@ghost ghost self-assigned this May 19, 2020
@ghost
Copy link
Author

ghost commented May 19, 2020

One way this could play, discussed during API Working Group, is that we deprecate the creds-init behaviour entirely and remove it when switching to v1beta2. It's a holdover from the very earliest days of Tekton / Knative Build so it simply might not make sense to retain the behaviour much longer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

0 participants