A developer may need temporary access to a database that accepts connections only from the cluster’s network. The historical socat-tunneller chart ran a relay pod: a Kubernetes port-forward connected to it, and it forwarded traffic to the selected backend host and port. The chart is deprecated. The relay supplies network reachability, not database authentication or encryption, so its permitted users, destination and lifetime need to be controlled separately from the credentials used at the backend.
Current guidance
The original chart wraps socat in a pod so kubectl port-forward can reach a host accessible from the cluster, such as a private database. Its README explicitly marks the chart unsupported. The tool is a transport relay; it does not add database authentication, encrypt an otherwise plaintext backend connection or determine whether a user is authorized to query business data.
For occasional access, define a narrowly scoped, temporary forwarding workload or use the platform’s supported access mechanism. Restrict its destination and egress, avoid broad host-network privileges and verify who can create pods or open port-forward sessions in that namespace. Kubernetes access and database credentials are separate authorization layers.
Before replacing an inherited deployment, record the target hostname, port, DNS behavior and client TLS verification requirements. Test connectivity with a low-privilege account and confirm that the relay cannot become a general path to unrelated internal services. Remove idle relays and their RBAC when the session or use case ends. No maintained drop-in chart successor was established here, so the old Helm command remains historical rather than a new installation recipe.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
A port-forward proxy. Allows an onward connection from the cluster to some other host in your cluster’s network, eg your hosted database/cache/other service.
In practice, this means that a hosted service can be made available only to the cluster, then cluster users can be granted access by giving them permission to run port-forward on the tunneller.
Basic usage
|
1 |
helm install stable/socat-tunneller --name db-tunneller --set tunnel.host=mydbhost.cloud --set tunnel.port=3306 --set nameOverride=db-tunneller |
then:
|
1 |
kubectl port-forward svc/db-tunneller 13306:3306 |
then, for example:
|
1 |
mysql -u myuser -h 127.0.0.1 --port 13306 -p |
Sources & further reading
Spotted something that needs another look?
Help improve this page →