The GID defined by "USER" in Dockerfile does not work in container of Pod

Question

What happened: Add "USER 999:999" in Dockerfile to add default uid and gid into container image, then start the container in Pod , its UID is 999, but its GID is 0.

In container started by Docker the ID is correct

docker run --entrypoint /bin/bash -it test

bash-5.0$ id
uid=9999 gid=9999 groups=9999

But start as Pod, the gid is 0

kubectl exec -it test /bin/bash
bash-5.0$ id
uid=9999 gid=0(root) groups=0(root)
bash-5.0$

bash-5.0$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin 
systemd-coredump:x:200:200:systemd Core Dumper:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
systemd-resolve:x:193:193:systemd Resolver:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin

If Dockerfile run extra "useradd" command , then it seems the gid is ok in Pod

RUN useradd -r -u 9999 -d /dev/null -s /sbin/nologin abc 
USER 9999:9999

then the ID in container of Pod is the same as set in Dockerfile

bash-5.0$ id uid=9999(abc) gid=9999(abc) groups=9999(abc)

What you expected to happen: the GID of container in Pod should also 999

How to reproduce it (as minimally and precisely as possible): Dockerfile add "USER 999:999" Then start the container in Pod

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: test
      imagePullPolicy: Never
      command: ["/bin/sh", "-c", "trap : TERM INT; sleep infinity & wait"]

Environment:

Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

OS (e.g: cat /etc/os-release): Fedora release 30 (Thirty)

docker version Client: Version: 18.09.9 API version: 1.39 Go version: go1.11.13 Git commit: 039a7df9ba Built: Wed Sep 4 16:52:09 2019 OS/Arch: linux/amd64 Experimental: false

Server: Docker Engine - Community Engine: Version: 18.09.9 API version: 1.39 (minimum version 1.12) Go version: go1.11.13 Git commit: 039a7df Built: Wed Sep 4 16:22:32 2019 OS/Arch: linux/amd64 Experimental: false

I see you're using `:latest` and a `PullPolicy` of `Never`; are you sure the image is the one you think it is? Using its [image hash](https://stackoverflow.com/a/33511811) can be a good way to verify that — mdaniel, Aug 05 '20 at 04:26
Yes, I use docker build to create image in local env just for the test . It seems no image hash with local build # docker inspect --format='{{.RepoDigests}}' abc:latest [] — Huang Shujun, Aug 06 '20 at 05:05
Interesting, so you're running minikube or something? Or building the image on the Node directly? — mdaniel, Aug 06 '20 at 16:02
In the question I build test on the Node directly. But actually using image which pull from repository also has same result. I have updated the Docker version in questions above. This Kubernets I used can be deployed as multiple nodes so I think it is not minikube. I will confirmed with the tool expert about what it is. How to see what it is ? Could you also try on your env I think it may have same result. — Huang Shujun, Aug 08 '20 at 11:31
Hi, I have update the /etc/passwd in above questions, it sees add them in the comments is too long. — Huang Shujun, Aug 08 '20 at 11:43
The interesting thing is if I add both useradd and USER in dockerfile. Then the uid and gid will be same as the USER set in container of Pod. Dockerfile: RUN useradd -r -u 9999 -d /dev/null -s /sbin/nologin abc USER 9999:9999 then id in container of Pod will be bash-5.0$ id uid=9999(abc) gid=9999(abc) groups=9999(abc) bash-5.0$ — Huang Shujun, Aug 08 '20 at 11:52
Does it mean the USER command in Dockerfile actually do not work in container of Pod? — Huang Shujun, Aug 08 '20 at 12:26

score 1 · Answer 1 · answered Aug 05 '20 at 04:24

1

I realize this isn't what you asked, but since I don't know why the USER directive isn't honored, I'll point out that you have explicit influence over the UID and GID used by your Pod via the securityContext:

spec:
  securityContext:
    runAsUser: 999
    runAsGroup: 999
  containers:
  - ...

answered Aug 05 '20 at 04:24

mdaniel

31,240
5
55
58

With runAsGroup, the gid is 999 in container of Pod, but I want to figure out the question. Maybe it is a bug of kubernetes or a limitation ? – Huang Shujun Aug 06 '20 at 04:56
It's for sure not a limitation or bug in kubernetes, there are countless images that run as non-root (elasticsearch is the most famous one I can think of); that's why I kept asking about **your** situation -- there is something weird going on for you that would cause that behavior, and my guess remains that the image you're running isn't the image you _think_ you're running – mdaniel Aug 06 '20 at 16:03
Sorry, I write wrong image name in question, but I did use same image during test. Could you also try to reproduce that. I think maybe others have no problem is because they use runAsGroup. They do not use UID and GID setting by docker "USER". – Huang Shujun Aug 08 '20 at 11:21

The GID defined by "USER" in Dockerfile does not work in container of Pod

1 Answers1