instrumentisto / coturn-docker-image

[Closed] Coturn TURN server Docker image
Other
191 stars 47 forks source link

Running turnserver as non-root using privileged ports #40

Closed equinox0815 closed 3 years ago

equinox0815 commented 3 years ago

Hi,

Due to open issues in Kubernetes and Docker it is currently surprisingly hard to run this container as non-root user and still use privileged ports. AFAIK there are at the moment two possible workarounds for this issue.

The sysctl based solution could be applied without changing the image but is IMHO a bad idea if the container is run using host networking. Also Kubernetes doesn't even start containers that use host networking that also have sysctl settings in their securityContext. Running the container in it's own network namespace brings a plethora of problems in and of itself and even then adding sysctl settings to a Kubernetes Pod is not really straigh-forward (as is documented here).

This leaves us with option two. Which of course is also problematic. For now my deployment opts for this solution but in order to do this i of course have to build custom images. This also has drawbacks but none of these are a real problem for me at the moment. The custom image is built using this Dockerfile:

FROM instrumentisto/coturn:4.5.2
RUN apk --no-cache add libcap && setcap CAP_NET_BIND_SERVICE=+ep /usr/bin/turnserver

It would be great if you consider to integrate this changes into the image. But of course i totally understand if you come to the conclusion that the change has too many bad side-effects. In this case at least the next person that runs into this problem has a chance to find this issue and is not forced to debug the problem for hours as i just did.

regards christian

tyranron commented 3 years ago

@equinox0815 thank you for the detailed description. I think this may be baked into some sort of custom entrypoint.

At the moment, this image won't accept any changes, but I'll consider this when moving it to upstream.

equinox0815 commented 3 years ago

@tyranron Thanks! Unfortunately a custom entrypoint won't work because setting the capabilities needs either root privileges or something like CAP_SETPCAP for the entrypoint script. Of course being able to run the entrypoint without elevated privileges is the whole point of my proposed change.

tyranron commented 3 years ago

@equinox0815 this is done in coturn/coturn#746

It will be released as a stable Docker tag in a while.