kubernetesfile-permissionsuser-permissionsuseridsecurity-context

Kubernetes, security context, fsGroup field and default user's group ID running the container

I'm new to Kubernetes and I'm trying to understand some security stuff.

My question is about the Group ID (= gid) of the user running the container.

I create a Pod using this official example: 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 the documentation, they say:

In the configuration file, the runAsUser field specifies that for any Containers in the Pod, the first process runs with user ID 1000. The fsGroup field specifies that group ID 2000 is associated with all Containers in the Pod. Group ID 2000 is also associated with the volume mounted at /data/demo and with any files created in that volume.

So, I go into the container:

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

I see that the first process (i.e. with PID 1) is running with user 1000 => OK, that's the behavior I expected.

 $ 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

Then, I create a file "testfile" in folder /data/demo. This file belongs to group "2000" because /data/demo has the "s" flag on group permission:

$ 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

Then, I create a subfolder "my-folder" and remove the "s" flag on group permission. I create a file "my-file" in this folder:

$ 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

I'm surprised that this file belongs to group "root", i.e. group with GID 0. I expected that it should belong to group "2000" according to this sentence in the documentation:

The fsGroup field specifies that group ID 2000 is associated with all Containers in the Pod

With the following commands, I see that user with UID "1000" in the container has primary Unix group "0", not 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 
...

Does anyone have some explanations?

Why is not the user's GID set to the value of "fsGroup" field in the Pod's security context?

Why the user's GID is set to 0 = root?

Is it a bug in Kubernetes (I'm using v1.8.0)?

Did I misunderstand the documentation?

Thanks!

Solution

  • Unfortunately, setting the primary group ID is currently not supported in Kubernetes, and will default to gid=0.

    There is an open issue for implementing this: https://github.com/kubernetes/features/issues/213