I'm looking at setting up BrowZer and I'm seeing it setup on the same server as the Ziti Controller - and I'm curious about best practices here. Currently I use HAProxy to handle all inbound connections on a single port and terminate via SSL, and I've started using OpenZiti Edge clients to connect internal-only services. Some services need to be accessible without a client via web browser which is where BrowZer comes in.
I have some very-public services such as webservers on my DMZ, and I'm wondering if BrowZer is better installed in that VLAN as opposed to the same machine/zone as the controller? I realize a "DMZ" is not ZTNA - however VLAN segmentation is still often recommended despite utilizing ZTNA and I think it's important to discuss the best "ordering" of these technologies as well.
Thoughts on what might be the best way to do it:
Web Browser > (Internet) > HAProxy (DMZ) > BrowZer (DMZ) > Ziti Controller (Trusted Services VLAN) > Service (on whichever internal VLAN it's in). Thoughts?
You ask about "ordering", but perhaps a visual topo example would help explain where things reside and how they connect.
The diagram below is one I drew a while back to explain how an org could run a MSFT RDP server, but keep it invisible to malicious actors on the internet. The concepts here still apply to your situation (just swap out Azure RDP and swap in your HAProxy):
As you can see, browZer involves multiple pieces; some are on the open internet, and some are inside your VPC.
Your HAProxy instance would be invisible to the internet (since it resides in your VPC with no inbound ports open). Your HAProvy would ONLY be accessible to the Identities (users) you authorize, and these connections happen over Ziti's mTLS-based zero-trust overlay network.
Thankyou for your reply. I understand how there are different components and how they allow greater security and can even make services dark, however I'm more-so talking about the underlay network and how each of the components are best placed in a segmented network. I drew a diagram here to showcase a simple example (where the controller/router are on one server and also do the binding to services).
The first diagram shows the current setup (keep in mind I use the reverse proxy for 2 classes of traffic "Fully public" like webservers containing public content, and also "Semi-Private" so webservers that are externally available but require login (and these I'm most concerned about protecting). I put BrowZer on the DMZ thinking it's the most "exposed" component and the controller/router should be better protected on a secure VLAN - is this correct thinking?
Another thought that came up as what about services that have a web interface, but also have a mobile app that attaches such as NextCloud, Jellyfin, Immich, Home Assistant? Will these Android apps be able to connect to the public hostname pointing to BrowZer just as a web browser can? If not, what is best practice here?
You cannot terminate TLS for any OpenZiti comms tech. It will probably be fine to terminate TLS in very certain circumstances around API invocations (like to the controller's REST api, etc), but in general, OpenZiti operates with mTLS from the client (inclusive of BrowZer's bits) to the OpenZiti Routers. As such, terminating TLS will break mTLS and things won't work.
With that said, HA proxy is useful for other things such as using it for host routing via SNI to have "all your ports be port 443" for example. I believe we covered this in a prior post, but this post is another good one to have a look at.
If it were me, I would put an edge router as close to the final destination/target as possible. Ideally, co-located is the best approach. That would be what we call "ZTHA" (zero trust host access) and all your services bind to the underlay on the loopback/127.0.0.1 and all your OpenZiti services offload to localhost/127.0.0.1 and OS firewalls block all inbound traffic. With this deployment model, every host is a DMZ of it's own.
That's not always feasible, so if you want to traverse your "trusted" network, then an edge router inside that trusted network is the next best plan, and everything else outside of that trusted zone and put into the DMZ is the right approach. I don't quite think that's what you have in your diagram from what i can tell. i would add a third layer.
@TheLumberjack Ahhh I think I understand now. I knew that OpenZiti could not be SSL-terminated due to mTLS but I did not realize BrowZer (Client > BrowZer) was the same, though it makes sense. I think the part I've been trying to wrap my head around is following best practices to still segment your network, even in a ZTNA environment, while also using Zero Trust concepts on top of that setup.
Putting an edge router per protected network/VLAN makes total sense and would be the next step for me, right now I've been learning with just the one edge router/controller setup.
Yeah, it's exeptionally common for people to start the journey exactly like you are. So you're right on track as far as I'm concerned. A router per VLAN is the natural next step and for many, I'm sure that's where they stop! These routers we often refer to as "private" routers since they are in private address space moreso than "public" address space. These routers are also quite useful to have as well because OpenZiti clients in that private address space could use those routers as onboard points as well ("edge listener" enabled).
After ZTNA, ZTHA is the next step to continually segment/reduce the "trusted network space" as small as possible.
OpenZiti also supports "link grouping" at the "overlay network" layer as well. This allows you to control precicely, which routers can connect to which routers. That might not be interesting to you now, but it might someday. This is a more niche usecase, but for those people who want it, link-grouping is very interesting and useful.
@curt can keep me honest here if I stray but BrowZer is for "websites from your browser" and not geared towards applications. The magic that BrowZer does relies on being in a browser. Generally speaking, I would not expect apps (not websites in your browser) will not work with BrowZer. For these sorts of devices, you really need to use the android/ios tunneler.
@TheLumberjack is correct. OpenZiti BrowZer is about supporting web apps that run in a Chromium-based web browser. Chrome/Brave on Android is supported today, but not iOS.
Mobile apps are a different beast, and would require the tunneler to be used.
A router per VLAN is the natural next step and for many, I'm sure that's where they stop! These routers we often refer to as "private" routers since they are in private address space moreso than "public" address space. These routers are also quite useful to have as well because OpenZiti clients in that private address space could use those routers as onboard points as well ("edge listener" enabled).