-
-
Notifications
You must be signed in to change notification settings - Fork 540
Description
... and that is disallowed in some cluster configurations.
Background
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 USER 1000
in the Dockerfile.
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 --user=0
to docker run
.
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.
Behavior
While waiting around for the Telepresence to start, if you examine its deployment, you'll see something like this:
$ kubectl get deploy teltest -o yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
...
spec:
...
status:
conditions:
...
- lastTransitionTime: 2018-04-25T20:36:56Z
lastUpdateTime: 2018-04-25T20:36:56Z
message: 'pods is forbidden: pod.Spec.SecurityContext.RunAsUser is forbidden'
reason: FailedCreate
status: "True"
type: ReplicaFailure
observedGeneration: 1
unavailableReplicas: 1
Eventually Telepresence crashes, complaining that it could not find its pod.
RuntimeError: Telepresence pod not found for Deployment 'teltest'.
(along with the usual nasty traceback and plea to file an issue)
Fix
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 USER=1000
in its Dockerfile.