I have recently taken interest in zero trust networks and managed to find this project.
I'm trying to achieve a network that is not bound by it's physical structure:
Let's say I have a VPS somewhere in a data center. I want to make it (it or some service running on it) available to a host in my local home network. Is it possible to connect these hosts through on of tools provided by OpenZiti?
Network and communications between its hosts should be controlled and authorized by central node:
A host placed somewhere in a network controls the whole network, authenticates new hosts, authorizes requests, enforces policies and notifies network administrators if anomalies happen.
Network should support legacy devices:
Devices that doesn't run an advanced operating system such as Windows or GNU/Linux should be allowed to operate in a network. Examples include: Printers, ESP32, Cheap IP Cameras
Other features include:
Transport layer encryption -> Data should be encrypted when leaving the device
Support for Private PKI
Is OpenZiti in scope of this use case and requirements? Are there examples of running a zero trust - openziti based home network?
Hi @Zduniusz, welcome to the community and to OpenZiti!
Perfect!
Very much. There are copious videos on the youtube channel doing this and plenty of forum posts for this. This is basically "OpenZiti 101" - accessing a service from 'anywhere' that isn't exposed to the Internet is often the first thing you should do. You learn a lot of the concepts when you do that.
This is the OpenZiti controller.
OpenZiti provides "tunnelers" for this purpose. Their job is to allow legacy "underlay" (TCP/UDP) traffic to be transported over OpenZiti's mesh to the final destination. We support ZTNA (network based zero trust) and ZTHA (host based, better than trusting a whole network range). You also have granular control over ports too. It's quite flexible.
It has true end to end encrption from OpenZiti node to OpenZiti node and has mutual TLS connections between individual parts of the overlay. It also transports secure protocols without inspecting/manipulating those protocols, allowing you to tunnel TLS/ssh/etc without worry but also allows you to tunnel insecure protocols with less concern. (when the traffic is outside the OpenZiti mesh, we can't make any statementsd about that traffic, of course)
There are LOTS of examples using home assistant, plex, you name it. most of that content does happen to be on the youtube channel or on the blog. sometimes it's here in the forum. If you want a few example videos you can look at things like:
Thank you so much, Clint, for your quick and very informative response!
I based these question on the models presented in "Building Secure Systems in Untrusted
Networks" by Evan Gilman and Doug Barth (O’Reilly) book. In case you've stumbled upon this book, can you give me some insight about how the OpenZiti implementation compares to the model presented by the book's authors?
New questions arose:
How are connections between hosts established through NATs and Firewalls.
Following the data center's example. Are routers connecting to each other using NAT hole-punching with STUN servers? How well does it work when the connection is unstable and behind very limiting NATs (Let's say a user on a smartphone connects through an LTE network while on a train)
Is variable-based trust implemented, if so:
Is there a Trust Engine that monitors user patterns and dictates how much to put trust in user risky operation
Is out-of-band authentication possible?
Let's say that there is a private service that the employee has to very rarely access, and if they need to, they must authenticate, for example, with a TOTP.
At this time, all traffic is brokered through an OpenZiti router and is done through a synthesized TCP connection. All traffic is encapsulated and sent through that one connection. The overlay network can route traffic based on that encapsulation. It's not STUN and not UDP, it's more like a TURN server. It works great for unreliable networks from my personal perspective but you should probably test it out and formulate your own opinion. I use OpenZiti on my android device all the time and lots of people use it on ios too.
No. At this time there's no notion of "partial" or "variable" trust. You either establish your trust, or you do not. OpenZiti does have posture-based decision making capabilities, but it's an all or nothing situation. You either satisfy an authentication/authorization attempt - or not.
TOTP is one of the 'posture-based' capabilities OpenZiti has, yes. I use it every day to access our chat app. The session is timed out after 30 minutes of not being online, after which I must re-enter my TOTP. While I remain online through the day, this posture is refreshed and I don't need to enter my TOTP. There are other posture checks. see Posture Checks | OpenZiti
There are two sites, one based in Warsaw - Poland and second one in London - UK
In Warsaw, there is a controller, a router and some services
In London, there is a router and some services
An employee working in the UK would want to access a service located in London
In this example, would the employee need to query the Polish controller and ask for authorization, or is it possible to have two controllers working in a master-slave dynamic?
It would certainly reduce latency and improve redundancy.
Yes. Practically speaking, imo, most of the time, humans are incapable of feeling this bit of latency. Seriously, try it out you'll find you as a human don't notice/feel it. Automated processes doing 100's/1000's of transactions might, but it depends on how the solution is implemented. It's a common concern, but I don't think I've ever had anyone say it was a deal breaker.
We are in the process of implementing this sort of functionality right now, actually. So, not released yet but very, very actively being developed. Read through the last 1.0+ changelogs ziti/CHANGELOG.md at release-next · openziti/ziti · GitHub and keep a watch out for when it's released to GA
Is it advisable to make authorization on a service rely solely on identity passed by a Ziti system?
Let's say a user wants to access the home assistant dashboard, since they are authenticated and authorized by a Ziti controller, we can safely assume that the user is actually permitted to access the service and no further authentication (Username and password) is needed.
Is this advisable and done in real-world environments?
Generally speaking, it's not done a lot but it is mostly because for most applications, such as HomeAssistant, they are not "OpenZiti aware" and aren't really capable of operating in this sort of mode.
That said, however, I've recently added OpenZiti support to the EdgeX Foundry suite of core microservices by integrating an OpenZiti SDK directly into those microservices. As such, I could make this exact decision and the EdgeX Foundry team agreed that it makes sense to allow OpenZiti to offload some of that authorization work.
I would say this situation is entirely a case-by-case type of decision. I don't think there's any sort of "best practice". Sometimes that makes sense, sometimes you might want to layer on other authorization schemes.
When preparing for the final production deployment, concerns about network availability arose.
I'm concerned with the single point of failure being the network controller and the lack of autonomous functioning per site basis.
If there's maintenance on the controller's server, the whole networks grinds to a halt.
If a network were disconnected on a site, every device on a specific site wouldn't be able to communicate with each other.
I believe that there should be a local authority at each site, and these networks should then be connected on a per-policy basis.
This solution would render the whole network more robust, and there would be no single point of failure.
YES! Love that book, was my first read when I joined NetFoundry (the company behind OpenZiti) as I needed to learn what 'zero trust' was
One part I have referenced a lot is the idea of a 'Hardware-based Zero Trust Supplicant' (HBZTS) on pg. 140. This centers around devices/systems which cannot install a zero trust agent - they give the example of HVAC. They theorise a HBZTS as a low cost device which has a hardware identity (TPM chip etc) which can be consumed by the zero trust overlay and plugs directly into a legacy device's Ethernet port. You can then pair the two in your inventory management system can allow for seamless integration between legacy devices and a zero trust network. As soon as the HBZTS intercepts the protocol it encapsulates packets to provide identity, encryption (e.g., mTLS, E2EE), authentication/authorisation etc to whatever on the other side of the overlay network (hosting or accessing services). They kept it only as an idea though, as they stated at the time that a ZTBHS was pure fantasy.
When we created OpenZiti though this statement was no longer correct. OpenZiti can be installed on a low cost device, and provide exactly this functionality. Uniquely we can solve it in different ways too, due to our development of SDKs - for example, I am working with an industrial process automation company which is using the C SDK to embed ZTN into their industrial HW.
As Clint points out though, they position zero trust technology in slightly different ways to which OpenZiti operates as they were applying ZT with technology that existed at the time, not what OpenZiti would make possible. For example, (but don't quote me as its been many years since I read it), I am very sure they suggest using different technologies for north-south vs east-west traffic (pretty sure the former was IPSec), whereas we built OpenZiti to implement zero trust networking principles for any use case, N-S or E-W.
Finally, while I am sure Clint (or others) will give a better answer, your concern is valid but not completely correct. If the controller is unavailable (in non-HA), the network does not grind to a halt. Existing, authenticated connections in the data plane will continue, only new connections cannot be made. For the last few years we have been developing HA controllers, currently released in Alpha-3 (Release v1.1.1 · openziti/ziti · GitHub, Controller HA · GitHub).
