yuvipanda / kubessh

SSH into a kubernetes pod per user
Apache License 2.0
48 stars 11 forks source link

Support SSH Tunneling #4

Open yuvipanda opened 6 years ago

yuvipanda commented 6 years ago

Tunneling requires we:

  1. Get info from client on target ip and target port
  2. Create a kubectl exec into the target pod, executing socat in the form of socat - TCP:<target-ip>:<target-port>
  3. Pipe stdin / stdout of the kubectl exec to the inbound TCP connection
mvoelske commented 4 years ago

For local port forwards there might be an even easier way: with a cluster network configured according to spec the kubessh pod should be able to connect to any port on the user pod over the cluster-internal network and pass it along. If target-ip is somewhere other than the user pod, we'd still need socat though, at least if remote port forwards are actually supposed to go through the user pod.

yuvipanda commented 4 years ago

I actually implemented this already in some form in https://github.com/yuvipanda/kubessh/blob/master/kubessh/server.py#L55, via kubectl port-forward. kubectl port-forward internally uses socat. I didn't want to just talk to the user pod, because:

  1. I wanted to support running the kubessh process locally while the user pods ran in minikube (maybe not that big a deal?)
  2. I wanted people to be able to tunnel to processes listening on localhost on the user pod, since that can't be accessed from outside the pod.

To deal with (2), we could host a sidecar, since it will be in the same network namespace. However, that isn't needed quite yet.

mvoelske commented 4 years ago

I actually implemented this already in some form in https://github.com/yuvipanda/kubessh/blob/master/kubessh/server.py#L55, via kubectl port-forward.

cool, I totally missed that! I just tried once with localhost instead of 127.0.0.1 in the ssh command, and assumed that wasn't implemented yet ;)

I didn't want to just talk to the user pod, because:

that makes sense, (1) is super useful for debugging/testing, and (2) is expected behavior from a ssh port forward