Open aldeed opened 1 year ago
Note that the workaround works for https Git repo, but with SSH there is still a Host key verification failed.
error
@tico24 - could you chime in on this one? I'm a little lost on the expected behavior for declaring a non-root user in a docker image and how that should play with a workflow?
@JPZ13 not really much to add? I'm guessing the inbuilt git artifact thing silently requires a root user and it shouldn't.
@JPZ13 @tico24 @terrytangyuan It's hard for me to know what the real issue is here because I don't know what is correct and what is wrong, but if it's helpful, this issue could also be described like this:
Your docs say that all containers run as root but actually they don't if the image has a non-root default user.
So there are two potential ways to fix:
If all containers should run as root:
If all containers should not run as root:
Edit:
By "non-root default user" I mean a Dockerfile like this:
FROM node:18-bullseye-slim
USER node
Remove that statement from the docs
We should probably remove the misleading statement. It seems inaccurate especially now that we only have the emissary executor.
Fix the Git feature so that it clones the repo using the same default user, OR provide an option to force it to run as root
@JPZ13 @caelan-io @rohankmr414 @weafscast Any update on https://github.com/argoproj/argo-workflows/pull/11149? We should move back to upstream go-git and check if the newest version already has an option for this.
Agreed. Great to see go-git is maintained again.
We paused our efforts on go-git as we thought @weafscast had a draft PR. Let us know if we should pick it back up.
We paused our efforts on go-git as we thought @weafscast had a draft PR. Let us know if we should pick it back up.
Yes, feel free to pick it up since it's been quiet for a while.
That all sounds good. It's more of a separate feature request, but I do think that having a way to force it to run as root would be useful even after the Git issue is fixed. I tried runAsUser: 0
but it seems to ignore it. If you agree, I can submit an enhancement proposal.
Yes feel free to submit an enhancement proposal. We'll see if other community members are also interested and then prioritize accordingly.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Pre-requisites
:latest
What happened/what you expected to happen?
Setup:
git
input artifact typeUSER node
in its Dockerfile (or most likely, any image that does not run as root by default)As the container command, try to run any git command that needs to write to the filesystem. For example,
git fetch
. There will be an error logged and a 128 exit code.The initial error suggests running
git config --global --add safe.directory /tmp/repo
, but if you do that, you just get a different permission error.Here's the logging from running the provided reproduction workflow:
Workaround
Setting the security context seems to work as a workaround:
When I do that, the repo directory is owned by that user.
But something seems incorrect because these docs say "By default, all workflow pods run as root", and yet when the image has
USER node
default, thenwhoami
printsnode
and these errors happen.Possible solutions
If possible, ensure that the repo is cloned by (owned by) the image's default user. Alternatively, if the intention is to override images to always run as root regardless of their default user, then that seems to not be happening.
And
securityContext
does not seem to have arunAsRoot
option, so it would then be impossible to run as root if that's not the default user in the image.Version
v3.4.8
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container