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

8/5/2020

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

-- Huang Shujun
docker
kubernetes

1 Answer

8/5/2020

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:
  - ...
-- mdaniel
Source: StackOverflow