GID, определенный параметром «USER» в Dockerfile, не работает в контейнере Pod. - PullRequest
0 голосов
/ 05 августа 2020

Что произошло: Добавьте «USER 999: 999» в Dockerfile, чтобы добавить uid и gid по умолчанию в образ контейнера, затем запустите контейнер в Pod, его UID равен 999, но его GID равен 0.

In контейнер запущен Docker, идентификатор правильный

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

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

Но запускается как Pod, gid равен 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

Если Dockerfile запускает дополнительную команду «useradd», то кажется, что gid в Pod

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

, тогда идентификатор в контейнере Pod такой же, как установлен в Dockerfile

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

Что вы ожидали: GID контейнера в Pod должен также 999

Как его воспроизвести (как можно точнее и минимальнее): Dockerfile добавить «USER 999: 999» Затем запустить контейнер в 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 версия Клиент: Версия: 18.09.9 Версия API: 1.39 Go версия: go1.11.13 Git фиксация: 039a7df9ba Создано: среда, 4 сентября, 16:52:09 2019 OS / Arch: linux / amd64 Экспериментальный: false

Сервер: Docker Engine - Community Engine: Версия: 18.09.9 API версия: 1.39 (минимальная версия 1.12) Go версия: go1.11.13 Git commit: 039a7df Построено: среда, 4 сентября, 16:22:32 2019 OS / Arch: linux / amd64 Экспериментально: false

1 Ответ

1 голос
/ 05 августа 2020

Я понимаю, что это не то, о чем вы спрашивали, но, поскольку я не знаю, почему директива USER не соблюдается, я отмечу, что вы оказывает явное влияние на UID и GID, используемые вашим модулем. через securityContext:

spec:
  securityContext:
    runAsUser: 999
    runAsGroup: 999
  containers:
  - ...
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...