Hi @markamind! Good question. Keep in mind that tproxy and host run modes of ziti-tunnel are deprecated by ziti-ege-tunnel, and so you should use ZET unless you have a particular reason for using the deprecated tunneler CLI. For example, if you need the proxy mode or if you’re modifying it in order to take advantage of Go language bindings to add some new capability.
Directly,
ziti-tunnel proxy provides a raw TCP proxy for the named service that is listening on the specified loopback TCP port and does not provide a DNS nameserver. This is an “opaque” proxy because the application must be “aware” of the particular proxy address and port in order to connect. For example, the client application can not naively connect to the hosted service, but must instead connect to TCP://localhost:5432 in order to communicate with the server that is published as Ziti service “private-postgres”.
ziti-tunnel tproxy is the “transparent” counterpart to proxy. This run mode provides a DNS nameserver and IPtables rules and IP routes in the OS so that client apps may connect to Ziti services transparently, naively, without being aware of the proxy at all. This mode is deprecated by ziti-edge-tunnel run.
ziti-tunnel host merely hosts services without providing any proxy for intercepting IP traffic, and does not provide a nameserver. This mode is deprecated by ziti-edge-tunnel run-host.
Get latest is just a script that uses curl to grab the latest zip file/tgz and unpack the archive in a place. You can look at the source to see how it’s doing things.
Hi @Metz, yes. The ziti tunnel proxy command still exists. When you say "sidecar," are you referring to a K8S pod or more generically, e.g., a Compose service?
today I'm still using docker-compose. But plan in future to move to k0s or k3s.
Is there an docker image available for the ziti-tunnel with proxy mode?
For this use case, you want the openziti/ziti-tunnel image because its entrypoint.sh has helpful functionality for enrollment. The image is produced from this Dockerfile whenever ziti is released. It's a thin veneer over the minimal ziti-cli image which itself merely provides the ziti executable.
You can provide any ziti tunnel sub-command as an arg to the openziti/ziti-tunnel image, i.e., proxy, tproxy, or host.
The proxy sub-command fits your use case because it does not require elevated privileges. However, this does introduce a bit of fragility because you must continually ensure the client proxy's bound services and ports are aligned with the dialing application.
Here's an excerpt from the K8S sidecar example that illustrates the env vars and paths you must configure for this container image. You can adapt this to use your desired sub-command instead of tproxy, and remove the additional capability NET_ADMIN since it's not necessary for proxy.
- image: openziti/ziti-tunnel
name: ziti-tunnel
args: ["tproxy"]
env:
- name: ZITI_IDENTITY_BASENAME
value: sidecar-client # the filename in the volume is sidecar-client.json
volumeMounts:
- name: sidecar-client-identity
mountPath: /netfoundry
readOnly: true
securityContext:
capabilities:
add:
- NET_ADMIN
You could use the same solution when you migrate to K8S, but there's not yet a Helm chart focused on this use case. There is, however, an established pattern for doing this with the openziti/ziti-router chart, which has the ziti tunnel features on-board when the router is created with tunnel mode enabled. Convenient, right?
I haven't mentioned this use case for the router yet in the K8S workload tunneling overview (I'll take an action to add that), but there's a section in the router chart's README about using proxy mode as a cluster service, optionally with Ingress.
