I've currently expirmented with deploying ziti controller in eks and gke kubernetes. It functions, can create services/routers/identieis etc.
My current deployment uses nodes that have external IPs.
But I'm afraid of the security implications of this.
- This would mean the nodes are all exposed to the public internet and could possibly be compromised?
- Does the ziti controller need access to the public internet in order to map requests between routers or am I misunderstanding this?
- Would it be possible to only expose the needed ziti client/management api endpoints used by routers/tunnels/cli?
Are my worries well founded?
Is there a specific pattern to deal with this concern?
Thanks
Yes. If there is an OpenZiti 0-day vulnerability, this would be a serious concern.
Yes. You would "split" the APIs, excluding the OpenZiti management from the public facing internet and exposing only the client API to the public internet. You MUST at least expose the client API to the internet.
A better way to think about it is any OpenZiti client needs to be able to connect to the OpenZiti controller client API. If all your clients are on private address space, you don't need to expose it to the internet. If you want to have access to your services from 'anywhere' -- it'll have to be exposed on the internet.
It'd be foolish to say no. Exposing anything on the internet comes with risks. But you can take steps to minimize all risk.
I believe removing the management API from the public internet is a good idea, but other than that I don't think it's a concern to expose the client API. (and of course, you'll need at least one edge router on the internet too)
hth
Hi @TheLumberjack , except the client connecting to controller url do controller or router itself want to route any requests over internet .
Earlier from our testing it seems we need atleast one publicly accessible router for all other private routers to work . so controller needs internet to talk to that one public router right ?
Yes. This is correct. You need at least one router that both "private" (a router deployed in private address space) can address. Generally, that means available on the internet.
As mentioned above -- ALL parts of an OpenZiti overlay network need to be able to communicate to the OpenZiti controller. SDK clients will connect to the controller using the client REST API. Routers will connect to the controller via the routers control plane port. Router will connect to other routers to form a mesh.
This video goes over each of these ports and I'd recommend anyone interested in understanding how these pieces communicate watch it. This video uses the "express install" and uses separate ports and separate host names for each component just to make it easier to understand (hopefully) but you can use SNI and ALPN to reduce the total ports from four (4) to two (2) or even one (1).
Hope that helps
1 Like
Building on @TheLumberjack's comment on "Yes. If there is an OpenZiti 0-day vulnerability, this would be a serious concern." and " It'd be foolish to say no. Exposing anything on the internet comes with risks. But you can take steps to minimize all risk."
I would say that OpenZiti is designed to be very resistant to external malicious actors trying to reach and compromise the actual 'services' which OpenZiti is transporting and protecting. We get this question often, sometimes in the form of "You have only moved the port from source/destination to your overlay. As an attacker, I will now just attack the overlay". While technically true, it misses how Ziti adds many extra protections. I have written a short response below, I wrote it up in a longer form Linkedin post here - Philip Griffiths on LinkedIn: No Listening Ports?
First things first. Yes. If a vulnerability exists in the overlay network that would allow an attacker to bypass the security of the zero trust network, but what does that mean in practice? Well, to do this they would need to:
- (1) need to bypass the mTLS requirement necessary to connect to the data plane (note, each hope is uses its own mTLS with its own, separate key).
- (2) have a strong identity that authorizes them to connect to the remote service in question (or bypass the authentication layer the controller provides through exploits; note again, each app uses separate and distinct E2EE, routing, and keys)
- (3) know what the remote service name is, allowing the data to target the correct service (not easy as OpenZiti has its own private DNS that does not need to comply to TLDs)
- (4) bypass whatever "application layer" security is also applied at the service (ssh, https, oauth, whatever)
- (5) know how to negotiate the end to end encrypted tunnel to the 'far' identity
1 Like
A better way to think about it is any OpenZiti client needs to be able to connect to the OpenZiti controller client API. If all your clients are on private address space, you don't need to expose it to the internet. If you want to have access to your services from 'anywhere' -- it'll have to be exposed on the internet.
Okay. I think I'm understanding this better now.
I think I got confused by the diagram below, which shows private router in a private network.
And was confused what was meant by "private" for the private router if it has to be publically accessible to the internet in order for the public routers to be able to link to them.
Is it fair to say, all nodes that ziti routers and tunnel are deployed on will need access to the internet with one of (public external IP or NATGW) in order to join the data mesh?
- In this diagram below it would be each router (including private routers) have public internet access..
- also if the applicatoin wanted to use ziti tunnel to make requests over the ziti network. the tunnel would also have to run in a node with internet access while also being accessible to the applicatoin server.
I sort of just answered this on your other post I think...
I assume you want secure, ubiquitous connectivity from anywhere in the world. To do this you'll need to deploy the controller and one router (at least) on the internet with public IPs and with "allow" firewall rules, allowing clients to connect to the controller and to the router.... This is what is shown in the diagram.
They need outbound access to the internet - yes but outbound only. Otherwise the private routers couldn't connect to the public routers. But the private routers, are private. DENY ALL inbound traffic, no public ports open.
Nearly the same answer as for routers. It needs outbound internet access to the controller, but it does not necessarily need outbound access to the router. It COULD access the private router in private address space and if that private router was linked to the public router, then the service could be accessed.
1 Like
