0

Based on the official docs:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

Since fsGroup field is specified, all processes of the container are also part of the supplementary group ID 2000. The owner for volume /data/demo and any files created in that volume will be Group ID 2000.

However, it seems the document is not accurate enough. I found a lot of bug reports about different tools and frameworks, as well as some answers at SO, which suggest that it's not as simple as that.

Now, I myself have a similar situation. I have Wordpress deployed in GKE and its wp-content dir mounted as Persistent Volume. I set fsGroup 65534 for the entire Pod, which according to the docs should enforce supplementary group on all processes inside all containers. But I don't think that it can be enforced regardless of how processes are spawned. It probably even contradict Unix security architecture.

Back to my example: I can't store new files from Wordpress UI into wp-content folder because the permission is denied. I entered Wordpress container and here's what I see:

131111 drwxr-sr-x  4    65533 65533  4096 Dec  9 22:28 rev-f2380fe737e72b1749f98b69fca3e5a739502313

(rev dir is symlinked to by wp-content. I use git-sync for that). Now, I check the processes:

root@my-wp-deployment-64647c8bcb-9hv7j:/var/www/html# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.8 238516 34392 ?        Ss   Dec09   0:03 apache2 -DFOREGROUND
root         118  0.0  0.0   3868  3276 pts/0    Ss+  Dec09   0:00 /bin/bash
www-data     843  0.0  2.8 342704 114056 ?       S    09:39   0:01 apache2 -DFOREGROUND
www-data     855  0.0  2.4 334936 98624 ?        S    09:39   0:01 apache2 -DFOREGROUND
www-data     857  0.0  2.6 342484 108112 ?       S    09:39   0:02 apache2 -DFOREGROUND
www-data     859  0.0  2.6 335032 106760 ?       S    09:39   0:02 apache2 -DFOREGROUND
www-data     932  0.0  2.4 334888 98976 ?        S    10:33   0:01 apache2 -DFOREGROUND
www-data     934  0.0  2.8 345308 116380 ?       S    10:33   0:01 apache2 -DFOREGROUND
www-data     938  0.0  2.4 337084 99040 ?        S    10:33   0:01 apache2 -DFOREGROUND
www-data     940  0.0  2.5 339356 104144 ?       S    10:33   0:02 apache2 -DFOREGROUND
www-data     946  0.0  2.1 328920 87932 ?        S    10:33   0:00 apache2 -DFOREGROUND
www-data     966  0.0  2.1 326644 84796 ?        S    10:56   0:00 apache2 -DFOREGROUND
root         975  0.0  0.0   3868  3180 pts/1    Ss   11:06   0:00 /bin/bash
root         989  0.0  0.0   7640  2708 pts/1    R+   11:14   0:00 ps aux

And now I aslo check user's group affiliation:

root@my-wp-deployment-64647c8bcb-9hv7j:/var/www/html# groups root
root : root
root@my-wp-deployment-deployment-64647c8bcb-9hv7j:/var/www/html# groups www-data
www-data : www-data

As I see, some of the users are not associated with 65534 and they are the once that initiate new processes.

Where's the catch? Am I missing something or is Kubernetes doc not accurate? Or both?:)

David Maze
  • 130,717
  • 29
  • 175
  • 215
yuranos
  • 8,799
  • 9
  • 56
  • 65
  • I see several issues with your question. First is that `groups` cmd shows only regular groups and it won't show you the suplementary groups. Try `ps a -o user,pid,ppid,supgid,group,cmd` to see supgrp of processes. Second is that `rev-xxx` dir has user and group of 65533 and you mentioned setting fsgroup 65534, but I assume its a typo. Third, looking at the permisions `drwxr-sr-x` i looks like permissions for group is read only, so I am not supprised you cannot write to rev dorectory. – Matt Dec 11 '20 at 13:32
  • Can you confirm that this is the case? Or correct me if I am missing something – Matt Dec 11 '20 at 13:33
  • @Matt, it must be a typo, but I will need to check it more thoroughly in terms of the last commits. – yuranos Dec 11 '20 at 17:19
  • As for the extended command with a check: root 118 0 65533 root /bin/bash; root 4739 0 65533 root /bin/bash; root 4744 4739 65533 root ps a -o user,pid,ppid,supgid,group,cmd – yuranos Dec 11 '20 at 17:20
  • So, yes, the 65533group is there. Thanks! But it's only root. What about www-data? – yuranos Dec 11 '20 at 17:21
  • Try `ps aux -o user,pid,ppid,supgid,group,cmd` to see all processes – Matt Dec 17 '20 at 15:15

0 Answers0