Feature Request: Kubernetes Tunnels

[knpwrs]

Add a mode = "kubernetes" (alias "k8s") so a cluster port-forward can be declared alongside SSH tunnels in .boring.toml and managed with the same open/close/list/group commands.

Example:

# forward a local port to a Service in the cluster
[[tunnels]]
name = "api"
mode = "kubernetes"
local = "8080"
remote = "svc/api:8080"
context = "staging"
namespace = "backend"

# forward to a specific Pod, current context/namespace
[[tunnels]]
name = "worker"
mode = "k8s"
local = "9000"
remote = "pod/worker-0:9000"

# group k8s + ssh tunnels together so `boring open -g dev` brings up everything
[[tunnels]]
name = "db"
mode = "kubernetes"
local = "5432"
remote = "svc/postgres:5432"
context = "dev"
group = "dev"

[alebeck]

Hi, thanks for opening, I really like it from a UX perspective. However it might be difficult to implement, as k8s authentication and port forwarding does not happen via SSH. So we'd have to import, e.g., client-go which would multiply the size of the app and arguably conflict with its lightweightness. Another approach would be shelling out to kubectl but that contradicts the current implementation/architecture, too. Let me know if you have any ideas but currently this seems to be low priority unfortunately.

[knpwrs]

My idea was going to be shelling out to kubectl. Honestly I thought this tool shelled out to ssh, it seems like a natural outsourcing of responsibilities to me.

[alebeck]

Got you! We actually use golang.org/x/crypto/ssh as the SSH client instead of shelling out to ssh(1). This gives better low-level control over tunnels, e.g. for sending keep-alives, set timeouts, or act on connection drops. Also it makes the software more portable. Therefore this is probably not going to happen for k8s tunnels anytime soon, as much as I would like it. Open for ideas though!

[knpwrs]

Hmm, maybe I should just make a k8s version and note the inspiration here. boring is such a good name for this tool though!

I suppose kuboring isn't the worst (as long as you don't mind such a project existing, and like I said, citing this repo as inspiration).

[alebeck]

Thanks! :)

Feel free to do that, and again, if you can scope a PR that's not too heavy we can consider including it in boring. I'd really like the UX but am concerned it would be too heavy, but who knows.

[knpwrs]

Just to confirm suspicions , I build a version that bundles in client-go from k8s, and the binary size does indeed grow by 4.7x.

[alebeck]

Thanks for checking! Do you think we can build the relevant parts ourselves? That would amount to (1) kubeconfig yaml parsing, (2) port forward streaming (presumably WebSocket is sufficient for 1.31+) and (3) support auth via exec credential plugins. The way I see it that would only add the yaml parser as an additional dependency, but we'd have to think about the architectural changes a bit more.