Bug: Jupyter and Jupyter-Notebook LISTEN too widely

[bjornrobertsson]

Bug/Security improvement: Jupyter modules bind to all interfaces unnecessarily

The two Registry modules for Jupyter Notebook and Jupyter Lab explicitly bind to all network interfaces (--ServerApp.ip='*'):

• https://github.com/coder/registry/blob/main/registry/coder/modules/jupyter-notebook/run.sh#L43
• https://github.com/coder/registry/blob/main/registry/coder/modules/jupyterlab/run.sh#L54

Combined with disabled authentication (--ServerApp.token='' --ServerApp.password=''), this exposes an unauthenticated Jupyter server to the entire network. In Kubernetes environments, any pod on the same network can connect directly, bypassing Coder's authentication layer.

Why this is unnecessary

Coder's port forwarding works through the agent locally, so Jupyter only needs to bind to localhost. The default Jupyter behavior (without --ServerApp.ip) already binds to localhost on both IPv4 and IPv6:

tcp6       0      0  ::1.8888               *.*                    LISTEN
tcp4       0      0  127.0.0.1.8888         *.*                    LISTEN

Proposed fix

1. Remove --ServerApp.ip='*' entirely (secure by default)
2. Add an optional host variable defaulting to localhost or 127.0.0.1 for users who explicitly need different behavior

[bjornrobertsson]

Parameters for localhost may need to be adjusted

  "$BASE_URL_FLAG" \
  --ServerApp.ip='127.0.0.1' \
  --ServerApp.port="${PORT}" \

--IdentityProvider.token='' \
--ServerApp.password='' \
--LabApp.allow_remote_access=True \

  > "${LOG_PATH}" 2>&1 &

More recent Jupyter versions may also require the last one to be:

--ServerApp.allow_remote_access='True'

### Needs to be tested and verified, and also the use of 'localhost' as a name could cause issues with IPv6 disabled deployments, where /etc/hosts still reflects ::1 localhost (but cannot listen)