Running Configurable proxy separately over a service

JupyterHub Zero to JupyterHub on Kubernetes
#1

While running the configurable-http-proxy seperately on a pod than the hub the proxy comes up and responds well when --ip and --api-ip is choosen to be 0.0.0.0 or local host. The Nodeport service on the pod over 8000 port gets a response. All good.

configurable-http-proxy --default-target=URL --ip=0.0.0.0 --port=8000 --api-ip=0.0.0.0 --api-port=8001

When we try to use the node port service’s ip and port directly in --ip and --port parameter it says address not found.

configurable-http-proxy --default-target=URL --ip=172.X.X.X --port=8000 --api-ip=0.0.0.0 --api-port=8001

14:38:18.474 [ConfigProxy] info: Adding route / → http://:
14:38:18.571 [ConfigProxy] info: Proxying http://172.X.X.X:8000 to http://:
14:38:18.571 [ConfigProxy] info: Proxy API at http://0.0.0.0:8001/api/routes
14:38:18.666 [ConfigProxy] error: Uncaught Exception: listen EADDRNOTAVAIL: address not available 172.X.X.X:8000
14:38:18.666 [ConfigProxy] error: Error: listen EADDRNOTAVAIL: address not available 172.X.X.X:8000
at Server.setupListenHandle [as _listen2] (net.js:1301:21)
at listenInCluster (net.js:1366:12)
at doListen (net.js:1503:7)
at processTicksAndRejections (internal/process/task_queues.js:81:21)

The behavior is same when using Node IP and corresponding port.
The Nodeport service is valid since it was already tested when proxy worked on 0.0.0.0.

Is it mandatory to open the proxy on 0.0.0.0 only to detach the hub and proxy ? Is it because it can update the table with local address only.

Apologies if it is a lame question, but seems like must have been tried already.

#2

Kubernetes has multiple layers of abstractions including a virtual network. For example, nodes, services and pods all have their own IPs, and all are part of the virtual network. In general your application can only bind to the pod’s IP.

#3

Since http proxy bind address needed to be known by Jupyter, POD Ip is not sustainable solution. Then the only option left is 0.0.0.0. Not a good choice for least privilege model.
That being said there does not seem to be good option to run Jupyter and configurable proxy running is separate POD without compromising on security.

#4

Could you expand on what your concerns are regarding 0.0.0.0, especially given the Kubernetes abstraction model and network security policies? Do you have an example of another Kubernetes application that behaves differently?