Skip to content
This repository was archived by the owner on Nov 23, 2020. It is now read-only.

Support SSH Tunneling #4

Open
yuvipanda opened this issue Apr 17, 2018 · 3 comments
Open

Support SSH Tunneling #4

yuvipanda opened this issue Apr 17, 2018 · 3 comments

Comments

@yuvipanda
Copy link
Owner

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
Copy link

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
Copy link
Owner Author

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
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants