Kubernetes -, Sicherheits-Rahmen, fsGroup Feld-und Standard-Benutzer-Gruppe-ID Ausführung des Containers

Ich bin neu Kubernetes und ich versuche zu verstehen, einige security-Kram.

Meine Frage ist, über die Gruppen-ID (= gid) des Benutzers ausgeführt, der container.

Ich einen Pod mit dieser offiziellen Beispiel: 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

In der Dokumentation, dass Sie sagen:

In der Konfigurationsdatei, die ausführenals Feld gibt an, dass für alle
Behälter in den Pod, der ersten Prozess läuft mit user-ID 1000. Die
fsGroup Feld gibt an, dass Gruppen-ID 2000 ist im Zusammenhang mit allen
Container in der Pod. Gruppen-ID-2000 ist auch im Zusammenhang mit der
volume in /data/demo mit allen Dateien erstellt, die
volume.

So, ich gehe in die container:

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

Sehe ich, dass der erste Prozess (z.B. mit der PID 1) ausgeführt wird, mit dem Benutzer 1000 => OK, das ist das Verhalten, das ich erwartet hatte.

 $ 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

Dann erstelle ich eine Datei "testfile" im Ordner /data/demo. Diese Datei gehört der Gruppe "2000", weil /data/demo hat den "s" - flag auf Gruppe-Berechtigung:

$ 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

Dann erstelle ich einen Unterordner "mein Ordner", und entfernen Sie die "s" - flag auf der Gruppe auch die Berechtigung. Ich erstelle eine Datei "meine-Datei" in diesem Ordner:

$ 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

Ich bin überrascht, das diese Datei gehört der Gruppe "root", also der Gruppe mit der GID 0.
Ich erwartete, dass er gehört zur Gruppe "2000" nach diesem Satz in der Dokumentation:

Den fsGroup Feld gibt an, dass group-ID 2000 ist im Zusammenhang mit allen
Container im Pod

Mit den folgenden Befehlen, die ich sehe, dass Benutzer mit der UID "1000" in der container primäre Unix-Gruppe "0", nicht 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 
...

Hat jemand ein paar Erklärungen?

Warum nicht der user ' s GID gesetzt, um den Wert von "fsGroup" - Feld in dem Pod security-Kontext?

Warum der user ' s GID auf 0 gesetzt = root?

Ist es ein bug in Kubernetes (ich bin mit v1.8.0)?

Habe ich missverstehen die Dokumentation?

Dank!

InformationsquelleAutor Sylmarch | 2017-12-29