Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
USER command should not require user or group IDs to exist #477
It is common for a Dockerfile to contain a USER directive of the form
Interestingly, while creating a minimal dockerfile to demonstrate this I discovered that Kaniko errors in two different ways:
Working example using Docker:
Kaniko failure mode 1
Kaniko failure mode 2:
@miguelitoq76 I assume you didn't mean to have two FROMs?
In case you really did mean to have the two FROMs:
I have done some further investigation and the behaviour is even more erroneous than I first thought!
Here I build three images containing the kaniko executor binary. One pulls the binary into a scratch base, the next into an alpine base, and the next creates a user within the image.
I build the three separate images:
And here I build the usertest3 image using kaniko inside each of those images.
kaniko binary in scratch
kaniko binary in alpine
As you can see, kaniko is erroneously looking for the /etc/passwd file in the environment in which kaniko is running, not the filesystem of the image it's building! Note it shouldn't even look for a passwd file at all when IDs are specified rather than names.
kaniko binary in alpine with an existing user:
Until the first RUN directive causes
It looks like this is also an issue when using
I encountered the same problem with a Dockerfile which has relevant lines like:
and it fails with the same problem as above.
I think it is a regression introduced somewhere between 3 Oct and 15 Nov. I use kaniko invoked from skaffold and skaffold v0.18 works fine (it uses kaniko v0.4 from 3 Oct) but v0.19 fails (it uses kaniko @ commit 0c29413 from Nov 15). skaffold v20 with kaniko v0.7 fails as well with the same problem.
Maybe this might help to pinpoint the problem.
I think it's just this line
Since all the code does is gets a User object and then returns the UID (which would match the userStr that we looked up in the first place) I feel like the correct behavior would be something like:
edit: playing around with this a little bit one issue seems to be that environment variables like HOME won't be set automatically if you use a numeric userid but that can be worked around if needed.
referenced this issue
Feb 12, 2019
I think I was able to work around this just now by adding a minimal /etc/passwd to my container before the USER instruction.
ARG UPSTREAM_IMAGE=prom/alertmanager ARG UPSTREAM_TAG=v0.15.3 FROM $UPSTREAM_IMAGE:$UPSTREAM_TAG as upstream FROM scratch LABEL project=<my-project> COPY --from=upstream /bin/alertmanager /bin/alertmanager COPY --from=upstream /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt COPY --from=upstream /etc/nsswitch.conf /etc/nsswitch.conf # Work around Kaniko bug. COPY --chown=0:0 passwd /etc/passwd EXPOSE 9093 USER 4191718 ENTRYPOINT ["/bin/alertmanager"] CMD [ "--config.file=/etc/alertmanager/config.yml", \ "--storage.path=/alertmanager" ]
Kaniko build log:
(This Dockerfile is taking Prometheus' alertmanager, copying the binary and some other important stuff into a scratch container, and forcing it to run as a non-root user. Stripping down third-party images like this is part of the security process where I work.)
This is a clunky workaround and I'd still appreciate this bug being fixed.
Using gcr.io/kaniko-project/executor:debug allowed me to workaround this issue
When using executor:latest
When using executor:debug
Suffering from this as well on
With the latest version: