Hi there,
I am looking for a way to deploy ziti-edge-tunnel's as Docker containers being able to intercept without using network_mode: host.
I need to use docker internal networking as I need the ziti-edge-tunnel being used by other containers.
Is there a way to "internalize" all the intercepting? Maybe building a container with systemd etc.?
At this time, I don't think you can do that. You can deploy routers instead within docker and configure them in that way: Deploy the Router with Docker | OpenZiti
Maybe that will work?
I agree the router container is probably the best way. That approach gives you Ziti DNS for each container using the Ziti router as a "sidecar" (a shared Docker bridge network interface and loopback device, and DNS resolver).
The K8s sidecar example uses a different container to the same thing: openziti/ziti-tunnel. The tunnel container does not provide a router, which is often desirable, and is less well documented because ziti-edge-tunnel is the preferred, flagship tunneler for most things.
The openziti/ziti-tunnel container can provide Ziti DNS and transparent sidecar proxy the same way as the openziti/ziti-router container, but is simpler to orchestrate since it's fully autonomous and requires only a JWT, not requiring generating a config YAML.
Circling back to this: Is it possible to use a Zitified Application inside a docker without a router „proxy“?
Thanks!
Yes. If you've embedded zero trust directly into the application by embedding an OpenZiti ask into the application, you can literally deploy that app anywhere.
An application embedded solution has no reliance on adapting the underlay to the overlay so the network capabilities within docker (or wherever you deploy) are not relevant.
The appetizer demo is a great example of this: OpenZiti - open source zero trust networking! | OpenZiti. It's deployed out to Amazon fargate as a tiny container.
Does this still also allow to dial in a docker container/multiple containers as well?
We have multiple containers that all need to dial and bind to services. How would a bind approach look like with the router?
Binding a service with an identity is the same regardless of the tunneler software used.
Dialing, means dialing a service via intercept? Intercepts in docker can be quite confusing.
Overall, maybe you can clarify what you're question is? I'm not sure I understand what you're trying to do
Sure:
We have a server running multiple Docker Compose web services. Currently, each Docker Compose file includes a Ziti tunnel service with its own identity and roles.
However, our requirements have changed. Now, we not only need to bind to services within the containers but also connect to other Ziti services.
Does that also work when using ziti-router as tproxy instead of ziti-tunnel?
Yes, imo that's a great situation for using the feature of docker that @qrkourier discovered of allowing a container to be assigned as another container's "network". Routers have an "iptables" based intercept capability. What you can do is create a router just like you would have created a ziti-tunnel, ensure it's tunneler enabled, and have it use 'tproxy' as it's operating mode. When you do that, the router will be able to intercept services. Then, you assign the network of the other containers as the router.
You can see an example of that with Deploy the Router with Docker | OpenZiti
tproxy-demo-client:
image: busybox
network_mode: service:ziti-router
see how the service uses network_mode: service:ziti-router? that's the magic that enables the feature.
Got it and makes sense. However we the run into the problem that we can't use other docker networks anymore, right? For many applications we have multiple service communicating via docker networks with each other, databases etc.
I would expect you to be able to add those networks to the router, but I must admit I've not actually tested that myself for a while. I don't remember the details. Maybe @qrkourier does.
Your client application container joins the router sidecar container's network. They share a container network interface address in the Docker bridge, loopback interface, and DNS settings. This means that whichever Docker bridge the Ziti router is connected to is the bridge where the client application container is connected too.
Thank you. makes sense.
This Gist is a BASH script that demonstrates intercepting a web request sent by a regular busybox container in a Docker Compose project.
In case of missing file confusion, the Docker router article with the sidecar example linked earlier by @TheLumberjack refers to these files in GitHub: ziti/dist/docker-images/ziti-router at main · openziti/ziti · GitHub