Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Telepresence uses securityContext.runAsUser=0 to bind to privileged ports #617
... and that is disallowed in some cluster configurations.
Some clusters don't allow the processes running in containers in pods to run as root (uid=0). OpenShift is configured this way by default. The Telepresence deployment runs its processes as uid=1000 to avoid running afoul of this restriction. This is encoded into the deployment image by including
Sometimes the user's code wants to bind to a privileged port (port number < 1024, e.g., port 80/443 for HTTP/HTTPS). In that case, the code must run as root. When the Telepresence deployment is run in place of this code (swap-deployment) or otherwise needs to bind to a privileged port (the expose option is passed a low port number), it too must run as root.
Telepresence accomplishes this by using the same deployment image (uid=1000) and setting securityContext.runAsUser=0 in the deployment manifest. This causes Kubernetes to override the uid for the processes launched in the container, similar to passing
However, some clusters disallow the use of securityContext.runAsUser. Telepresence does not handle this case at the moment. The effect is that the Telepresence deployment never successfully gets a running pod, as the cluster security rules forbid the pod from starting.
While waiting around for the Telepresence to start, if you examine its deployment, you'll see something like this:
Eventually Telepresence crashes, complaining that it could not find its pod.
(along with the usual nasty traceback and plea to file an issue)
The straightforward fix to this issue is to avoid using securityContext.runAsUser=0 to run as root. When the user asks for a privileged port, launch a different image that does not include