dockerkubernetesgoogle-kubernetes-enginelibgosu

Why is Docker CMD running as chronos in GKE?

I have a pod and NodePort service running on GKE.

In the Dockerfile for the container in my pod, I'm using gosu to run a command as a specific user:

startup.sh

exec /usr/local/bin/gosu mytestuser "$@"

Dockerfile

FROM ${DOCKER_HUB_PUBLIC}/opensuse/leap:latest

# Download and verify gosu
RUN gpg --batch --keyserver-options http-proxy=${env.HTTP_PROXY} --keyserver hkps://keys.openpgp.org \
      --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 && \
    curl -o /usr/local/bin/gosu -SL "https://github.com/tianon/gosu/releases/download/1.12/gosu-amd64" && \
    curl -o /usr/local/bin/gosu.asc -SL "https://github.com/tianon/gosu/releases/download/1.12/gosu-amd64.asc" && \
    gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu && \
    chmod +x /usr/local/bin/gosu

# Add tini
ENV TINI_VERSION v0.18.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
ENTRYPOINT ["/tini", "--", "/startup/startup.sh"]

# Add mytestuser
RUN useradd mytestuser

# Run startup.sh which will use gosu to execute following `CMD` as `mytestuser`
RUN /startup/startup.sh
CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/helloworld.jar"]

I've just noticed that when I log into the container on GKE and look at the processes running, the java process that I would expect to be running as mytestuser is actually running as chronos:

me@gke-cluster-1-default-ool-1234 ~ $ ps aux | grep java
root        9551  0.0  0.0   4296   780 ?        Ss   09:43   0:00 /tini -- /startup/startup.sh java -Djava.security.egd=file:/dev/./urandom -jar /helloworld.jar
chronos     9566  0.6  3.5 3308988 144636 ?      Sl   09:43   0:12 java -Djava.security.egd=file:/dev/./urandom -jar /helloworld.jar

Can anyone explain what's happening, i.e. who is the chronos user, and why my process is not running as mytestuser?

Solution

  • When you RUN adduser, it assigns a user ID in the image's /etc/passwd file. Your script launches the process using that numeric user ID. When you subsequently run ps from the host, though, it looks up that user ID in the host's /etc/passwd file, and gets something different.

    This difference doesn't usually matter. Only the numeric user ID matters for things like filesystem permissions, if you're bind-mounting a directory from the host. For security purposes it's important that the numeric user ID not be 0, but that's pretty universally named root.