web-dev-qa-db-fra.com

Kubernetes, contexte de sécurité, champ fsGroup et ID de groupe de l'utilisateur par défaut exécutant le conteneur

Je suis nouveau sur Kubernetes et j'essaie de comprendre certaines choses de sécurité.

Ma question concerne l'ID de groupe (= gid) de l'utilisateur exécutant le conteneur.

Je crée un pod en utilisant cet exemple officiel: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod

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

Dans la documentation, ils disent:

Dans le fichier de configuration, le champ runAsUser spécifie que pour tous les conteneurs du pod, le premier processus s'exécute avec l'utilisateur ID 1000 . Le champ fsGroup spécifie que l'ID de groupe 2000 est associé à tous Conteneurs dans le pod . L'ID de groupe 2000 est également associé au volume monté dans/data/demo et à tous les fichiers créés dans ce volume.

Je vais donc dans le conteneur:

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

Je vois que le premier processus (c'est-à-dire avec PID 1) fonctionne avec l'utilisateur 1000 => OK, c'est le comportement que j'attendais.

 $ 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

Ensuite, je crée un fichier "testfile" dans le dossier/data/demo. Ce fichier appartient au groupe "2000" car/data/demo a le drapeau "s" sur l'autorisation de groupe:

$ 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

Ensuite, je crée un sous-dossier "mon-dossier" et supprime l'indicateur "s" sur l'autorisation de groupe. Je crée un fichier "mon-fichier" dans ce dossier:

$ 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

Je suis surpris que ce fichier appartienne au groupe "root", c'est-à-dire au groupe avec GID 0. Je m'attendais à ce qu'il appartienne au groupe "2000" selon cette phrase dans la documentation:

Le champ fsGroup spécifie que l'ID de groupe 2000 est associé à tous les conteneurs du pod

Avec les commandes suivantes, je vois que l'utilisateur avec l'UID "1000" dans le conteneur a le groupe Unix principal "0", pas 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 
...

Quelqu'un a-t-il des explications?

Pourquoi le GID de l'utilisateur n'est-il pas défini sur la valeur du champ "fsGroup" dans le contexte de sécurité du pod?

Pourquoi le GID de l'utilisateur est défini sur 0 = root?

Est-ce un bug dans Kubernetes (j'utilise la v1.8.0)?

Ai-je mal compris la documentation?

Merci!

kubernetesfile-permissionsuser-permissionsuseridsecurity-context
7
Sylmarch

Malheureusement, la définition de l'ID de groupe principal n'est actuellement pas prise en charge dans Kubernetes et sera par défaut sur gid=0.

Il y a un problème ouvert pour l'implémentation de ceci: https://github.com/kubernetes/features/issues/21

4
AlexBrand