Proxy and Access

Remote access to the current on-prem target should prefer a tailnet or direct kubeconfig path to honey. SOCKS proxy access remains a compatibility path.

Current Preferred Model

export KUBECONFIG=~/.kube/kubeconfig-honey.yaml
export KUBE_CONTEXT=honey
kubectl --context honey cluster-info

Relevant private-service examples stay tailnet-only:

• grafana-observability.taila4c78d.ts.net:3000
• loki-observability.taila4c78d.ts.net:3100
• tempo-observability.taila4c78d.ts.net:3200
• otlp-observability-grpc.taila4c78d.ts.net:4317
• bazel-cache-grpc.taila4c78d.ts.net:9092

SOCKS Proxy

For clusters behind a campus network or firewall, a SOCKS5 proxy through an SSH tunnel to a private host still works:

# Start a SOCKS5 proxy via SSH
ssh -D 1080 -fN honey@100.113.89.12

# Configure tools to use the proxy
export HTTPS_PROXY=socks5h://localhost:1080

Once the proxy is running, kubectl, tofu, and curl commands will route through it automatically via the HTTPS_PROXY environment variable.

Justfile Integration

The proxy-up recipe and bk / bcurl wrappers still exist for compatibility. They are not the preferred operator model when direct or tailnet-private access to honey exists.

just proxy-up         # Start SOCKS proxy
just bk get pods -A   # kubectl through proxy
just bcurl https://... # curl through proxy

Tailscale

For clusters accessible via Tailscale, no proxy is needed. This is the preferred remote operator path when available.

Direct private host access examples:

ssh honey@100.113.89.12
ssh bumble@100.88.101.107
ssh sting@100.85.46.118

Do not introduce a new public management surface for the cluster API.

See Also

• Clusters and Environments — namespace layout
• Quick Start — deployment walkthrough