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!
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