Kubernetes, контекст безопасности, поле fsGroup и идентификатор группы пользователей по умолчанию, на котором выполняется контейнер

Я новичок в Kubernetes, и я пытаюсь понять некоторые вещи безопасности.

Мой вопрос о ID группы (= gid) пользователя, запустившего контейнер.

Я создаю Pod, используя этот официальный пример: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

В документации говорится:

В файле конфигурации поле runAsUser указывает, что для любых контейнеров в модуле первый процесс выполняется с идентификатором пользователя 1000. Поле fsGroup указывает, что идентификатор группы 2000 связан со всеми контейнерами в модуле. Идентификатор группы 2000 также связан с томом, смонтированным в / data / demo, и с любыми файлами, созданными на этом томе.

Итак, я иду в контейнер:

kubectl exec -it security-context-demo -- sh

Я вижу, что первый процесс (то есть с PID 1) выполняется с пользователем 1000 => OK, это поведение, которое я ожидал.

 $ ps -f -p 1
 UID        PID  PPID  C STIME TTY          TIME CMD
 1000         1     0  0 13:06 ?        00:00:00 /bin/sh -c node server.js

Затем я создаю файл "testfile" в папке /data/demo. Этот файл принадлежит группе "2000", потому что / data / demo имеет флаг "s" на разрешении группы:

$ ls -ld /data/demo
drwxrwsrwx 3 root 2000 39 Dec 29 13:26 /data/demo
$ echo hello > /data/demo/testfile
$ ls -l /data/demo/testfile
-rw-r--r-- 1 1000 2000 6 Dec 29 13:29 /data/demo/testfile

Затем я создаю подпапку "my-folder" и удаляю флаг "s" в разрешении группы. Я создаю файл "my-file" в этой папке:

$ mkdir /data/demo/my-folder
$ ls -ld /data/demo/my-folder
drwxr-sr-x 2 1000 2000 6 Dec 29 13:26 /data/demo/my-folder
$ chmod g-s /data/demo/my-folder
$ ls -ld /data/demo/my-folder
drwxr-xr-x 2 1000 2000 6 Dec 29 13:26 /data/demo/my-folder
$ touch /data/demo/my-folder/my-file
$ ls -l /data/demo/my-folder/my-file
-rw-r--r-- 1 1000 root 0 Dec 29 13:27 /data/demo/my-folder/my-file

Я удивлен, что этот файл принадлежит группе "root", то есть группе с GID 0. Я ожидал, что он должен принадлежать группе "2000" в соответствии с этим предложением в документации:

Поле fsGroup указывает, что идентификатор группы 2000 связан со всеми контейнерами в модуле.

С помощью следующих команд я вижу, что у пользователя с UID "1000" в контейнере есть основная группа Unix "0" или 2000:

$ id
uid=1000 gid=0(root) groups=0(root),2000
$ cat /proc/1/status
...
Pid:    1
...
Uid:    1000    1000    1000    1000
Gid:    0   0   0   0
...
Groups: 2000 
...

У кого-нибудь есть объяснения?

Почему GID пользователя не установлен на значение поля "fsGroup" в контексте безопасности модуля?

Почему GID пользователя имеет значение 0 = root?

Это ошибка в Kubernetes (я использую v1.8.0)?

Я неправильно понимаю документацию?

Спасибо!

Источник

1 ответ

Решение

К сожалению, установка идентификатора основной группы в настоящее время не поддерживается в Kubernetes и по умолчанию будет gid=0,

Существует открытый вопрос для реализации этого: https://github.com/kubernetes/features/issues/213

Источник

Каталог, на котором есть "setgid", приведет к тому, что все файлы, созданные в этом каталоге, будут принадлежать группе каталога, а не группе владельца.

Сначала вы создали файл в каталоге с помощью s falg. Файл задается группой каталога - 2000. Затем вы сняли флаг s. Во втором файле указана основная группа пользователей - 0.

Это не имеет отношения к Kubernetes.

Источник
Другие вопросы по тегам