[release/1.7 backport] [CRI] fix additionalGids: it should fallback to imageConfig.User when securityContext.RunAsUser,RunAsUsername are empty

[thaJeztah]

backport of:

• [CRI] fix additionalGids: it should fallback to imageConfig.User when securityContext.RunAsUser,RunAsUsername are empty #8136
• Follow Up for #8136 #8370

---

What is the issue

I found a bug in setting runtime.Spec.Process.User.additionalGids in CRI server/sbserver.

If LinuxContainerSecurityContext.{RunAsUser,RunAsUsername} are empty, contained should fallback to the container image's Config.User for resolving the primary user and use it to inspect /etc/group in the container image for resolving additionalGids. But containerd always fallback to 0.

Fortunately, in the use of Kubernetes+containerd, the bug does NOT happen because kubelet always fills out LinuxContainerSecurityContext.RunAsUser from the image status (code) when image's Config.User is not empty. So ontainer_create_linux.go#L369-L370 can grab the correct user from the SecurityContext.

However, because the cri-api spec does not assume the behavior, which fills out LinuxContainerSecurityContext.RunAsUser from the image's Config.User, I think the code should be fixed.

CRI-O seems to handle this correctly. See here.

Reproduction

Version

root@primary:~# crictl version
Version:  0.1.0
RuntimeName:  containerd
RuntimeVersion:  1.6.16
RuntimeApiVersion:  v1

Image and Container Spec

The image everpeace/test:containerd-image-config is used.

# the image has alice(uid=1000)
root@primary:~# docker run -it --rm everpeace/test:containerd-image-config cat /etc/passwd | grep alice
alice:x:1000:1000::/home/alice:/bin/sh

# In the image
# - root belongs to an additional-group-for-root
# - alice belongs to an additiona-group-for-alice
root@primary:~# docker run -it --rm everpeace/test:containerd-image-config cat /etc/group | grep -e root -e alice
root:x:0:
Alice:x:1000:
additional-group-for-alice:x:10000:alice
additional-group-for-root:x:20000:root

# image specifies "config.user: 1000" (alice)
root@primary:~# crictl inspecti everpeace/test:containerd-image-config
...
  "info": {
    "chainID": "sha256:140469df148ed27972d663207bf92e11d6d11b046647532811ab0f7a297c0cb0",
    "imageSpec": {
      "config": {
        "User": "1000",
...

root@primary:~# cat pod-config.json
{
    "metadata": {
        "name": "test-sandbox",
        "namespace": "default",
        "attempt": 1,
        "uid": "hdishd83djaidwnduwk28bcsx"
    },
    "log_directory": "/tmp/tmp.AqRbZ4eV2s",
    "linux": {
    }
}

root@primary:~# cat container-config.json
{
    "metadata": {
        "name": "test"
    },
    "image": {
        "image": "everpeace/test:containerd-image-config"
    },
    "command": [
        "id"
    ],
    "log_path": "test.0.log",
    "linux": {}
}

The output

# Run the container
root@primary:~# crictl runp pod-config.json 
3323c5e01e65ae0a4663b6e7391eb1e81a6fccb9a6cda07b639e792798cdb11e
root@primary:~# crictl create 3323c5e01e65ae0a4663b6e7391eb1e81a6fccb9a6cda07b639e792798cdb11e container-config.json pod-config.json 
6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4
root@primary:~# crictl start 6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4
6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4

# 'additional-group-for-alice' expects to be attached because imageConfig.User=1000(alice).
# However, 'additional-group-gor-root' is attached instead.
root@primary:~# crictl logs 6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4
uid=1000(alice) gid=1000(alice) groups=1000(alice),20000(additional-group-for-root)

Notes for reviewers

The current containerd's CRI implementation doesn't follow the conversion spec config.User to spec.Process.User. The containerd's CRI impl

• doesn't support to specify group in config.User in the image, and
• ALWAYS attach groups from the image(/etc/group) when setting RunAsGroup in SecurityContext

The issue will be handled in kubernetes/enhancements#3619 separately to avoid breaking changes to the users.