Remote Clusters
Operate clusters KubeBolt can't reach directly — the in-cluster agent dials out, nothing dials in. Exec, port-forward, and the file browser all work over the tunnel.
Not every cluster is reachable from where KubeBolt runs — private GKE/EKS control planes, clusters behind a bastion, or networks with no inbound path. In agent-proxy mode an in-cluster agent opens an outbound connection to the KubeBolt backend and tunnels operations back over it. Nothing dials in: no exposed API server, no firewall holes, no VPN.
What works over the tunnel
This isn’t read-only mirroring — full-stack operation works against a remote backend:
- Terminal / exec — open a shell into a container.
- Port-forward — reach a service running in the remote cluster.
- File browser — navigate and read files inside a container.
Port-forward over HTTP
Port-forwards are tunneled over WebSocket and exposed through an HTTP reverse
proxy at /pf/{id}/, so the dashboard can open a forwarded service without
direct network access to the backend. Idle forwards close on a 5-minute timeout,
tuned separately from the exec timeout.
Known limitations. Apps that hard-code absolute root paths (/static,
/api) won’t render cleanly through /pf/{id}/ without a sub-path config on
the app itself — for example Grafana’s root_url. Raw TCP forwarding (for
databases) is on the roadmap; today’s port-forward path is
HTTP.
The HTTP remote path has been validated end-to-end across the public internet through a Caddy reverse proxy with TLS, with the operator agent running in a separate cluster from the backend.