3

I'm trying to understand how securityContext work in my cluster (k8s v 1.24 & the node is an Ubuntu 18.04).

I simply want to do a simple cat /dev/tty0 from the container.

Here is my simplified configuration of the node :

bash-4.2# ls -al /dev/tty0
crw--w---- 1 root tty 4, 0 Jul 25 05:16 /dev/tty0

bash-4.2# grep tty /etc/group
tty:x:5

I mounted /dev/tt0 to access it from the container & run the container with group Id 5 & userId 0 (i tried also without the runAsUser but the behaviour is the same)

spec:
  volumes:
    - name: tty
      hostPath:
        path: /dev/tty0
  containers:
    - name: mycontainer
      image: ...
      volumeMounts:
        - name: tty
          mountPath: /dev/tty0
      securityContext:
        runAsUser: 0
        runAsGroup: 5

When I log in the container:

bash-4.2# id
uid=0(root) gid=5(tty) groups=5(tty)
bash-4.2# ls -al /dev/tty0
crw--w---- 1 root tty 4, 0 Jul 25 05:16 /dev/tty0

But i cannot access /dev/tty0.

bash-4.2# cat /dev/tty0
cat: /dev/tty0: Operation not permitted

While from the node I don't have this error message.

This is just for testing purpose, my originale use case is the launching of Xorg but I get the Operation not permitted error message.

I tried adding the "privileged: true" securityContext, and with this it works. However, it is not a good practise to use this maximum capacity to the container and I'm trying to understand what is the minimal security context to give to the pod.

Thanks!

Ptiseb
  • 795
  • 1
  • 7
  • 19
  • Could it be that your group missing permissions to read the tty0, since you are running as group 5? – TheCoolDrop Jul 25 '23 at 09:12
  • It looks like you're trying to read from the physical console of whichever node in the cluster the Pod happens to be running on? I wouldn't be surprised if this were disallowed by default (and you'll run into bigger problems trying to run an X server on the host's display). I don't immediately see anything in a [pod spec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/) that would be equivalent to the `docker run --device` option. – David Maze Jul 25 '23 at 10:43
  • @TheCoolDrop yes you're right, i added the reading permission for the group tty (group #5) but I still have the same behaviour – Ptiseb Jul 25 '23 at 11:44
  • @DavidMaze, yes, Kubernetes does not have in its api the equivalent of --devive, we should use a plugin device instead. The thing is, in my case, if I grant elevated privileges (using securityContext - privileged true), i can access /dev/tty0 from within the container. But ideally I would like to find the minimum of rights to give to my container as I don't want to five full privileges – Ptiseb Jul 25 '23 at 11:44

1 Answers1

4

The securityContext specifies that the container should run as the user with UID0 and GID 5. When the container runs with root privileges, it still could have certain restrictions imposed by the underlying container runtime for security reasons.

In your case, the issue is, that accessing /dev/tty0 typically requires elevated privileges because it's a critical device file representing the first virtual terminal.

You can grant elevated privileges like this:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  volumes:
    - name: tty
      hostPath:
        path: /dev/tty0
  containers:
    - name: mycontainer
      image: ...
      volumeMounts:
        - name: tty
          mountPath: /dev/tty0
      securityContext:
        privileged: true

But attention, It's generally a good practice to run containers with the least privileged user necessary to perform their intended task, because running a container with root privileges can be dangerous as it allows direct access to system resources and can compromise the host system

pwoltschk
  • 550
  • 1
  • 3
  • 22
  • I agree with this, and this works. I forgot to mention it in my previous post (so I'll edit it), but the purpose of my test is to find the right securityContext to give to my pod to avoid to use "privilged: true", as you mention it, this is not a good practise. – Ptiseb Jul 25 '23 at 11:47
  • Hey, this is sadly not possible you need to have privileged access for dev/tty0 and you also can not grant it specifically for that. Either you grant it for the whole container or not. What you can do is carve out the "responsibility" to interact with /dev/tty0 of into an initContainer or a job. so the containers that work with elevated privileges are short-lived. – pwoltschk Jul 25 '23 at 13:49
  • OK, i see, I got it. I'll have a look to the device plugin in that case to see if it can solve my case. Thanks for the help & explanation! – Ptiseb Jul 25 '23 at 20:05