dovholuknf
Joined 5 years ago
Joined 5 years ago
I very much appreciate the "outsider" perspective though and thank you very much for sharing it. That perspective is impossible to obtain after you work on a project for long enough! :)
Cheers!
The project has been moving to supporting directly connecting to other identities but it hasn't been a priority yet.
The connections an OpenZiti identity makes to another OpenZiti identity are direct-over-OpenZiti (not direct over IP underlay) if that makes sense. I don't know if you'll ever be able to have two process communicate without that third 'arbiter' process (I'll call it). It might happen, but right now it seems less likely than the direct connect approach.
hope that helps. But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.
The productized version, NetFoundry Frontdoor (doc here https://netfoundry.io/docs/frontdoor/how-to-guides/create-mt...) is what offers mutual TLS support.
It'll still terminate TLS at the servers, though. It's not mTLS all the way through to the endpoint.
OpenZiti underpins the private connectivity from zrok, another opensource project and is one of the ones that is __not__ riding on wireguard which many people think is a good thing, but sometimes people are interested in a wireguard-based approach.
There is a huge list of alternatives as well you can find at https://github.com/anderspitman/awesome-tunneling. You can find OpenZiti and zrok on there but the github urls if interested are https://github.com/openziti/ziti and https://github.com/openziti/zrok
Maintainer here so I'm gonna be biased with this hot take, but I really don't agree with this particular sentiment.
I would turn it around instead and say that most indie hosters are maybe not looking for the levels of protection a zero trust overlay network provides. That is a believable reason for me why it might be perceived as not a good fit. If you're not looking for the sort of security that OpenZiti affords the operator, it will certainly feel less of a fit than a classic VPN-like solution. It also focuses on a different paradigm wrt connectivity centered around individual services. That does mean the learning curve is absolutely steeper because it's not "just IP" and all our years of ip-based-know-how are useful, but not to make the most of the system. While one can use IP/L3/L4 just fine with OpenZiti, it's certainly not trying to be an IP-based VPN (like many of the other solutions are). That also might lead to feeling like it's not a great fit.
For the people who want the sort of security OpenZiti provides, however. It really is an easy-to-use (my bias showing) solution that plenty of indie hosters use already. :)
Not trying to sound too defensive here (a little is ok, right?) but I also appreciate the comments and feedback, thank you!
> In a similar sense, why should enterprises trust OpenZiti?
you don't have to. It's open source - so you go look at all the code and judge for yourself but perhaps better than that (well different anyway) is that OpenZiti allows you to use your own PKI for identities if youlike. With third-party CA support, you can make your own key/cert and deploy them to identities if you desire. https://openziti.io/docs/learn/core-concepts/pki/#third-part...
> If services do not use e2ee
with OpenZiti you basically get this by default between OpenZiti clients. (once offloaded from the OpenZiti overlay, it's up to the underlying transport protocol)
The full zssh project is availalbe on GitHub at https://github.com/openziti-test-kitchen/zssh (I work on the OpenZiti project and support zssh among other things)