166 karma · joined August 25, 2021
The. fine. article. seems. to. say. lots. of. companies. are. using. Tailscale. to. connect. to. servers. with. GPUs. -- nothing. in. that. implies. that. Tailscale. would. own. the. GPUs.
Besides my joke, you are bang on, nothing implies needing to buy GPUs and based on my knowledge of their product/the space, absolutely no reason to.
TL:DR, we believe service meshes introduce complexity with control plane synchronization, service discovery challenges, and network overlays. A Global Overlay removes Kubernetes service dependencies and shifting networking to a Zero Trust, software-defined global overlay which is much simpler, automated and secure.
Super curious to get your thoughts.
- (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
So yes, if they can do all that, then they'd definitely be able to attack that remote service. Note, they only have access to 1 single service among hundreds, thousands, or potentially millions of services. Lateral movement is no possible. So the attacker would have to repeat each of the 5 steps for every service.
A colleague wrote this too, its from a slightly different angle but still very relevant - https://blog.openziti.io/no-listening-ports.
- Agreed. OpenZiti is not trying to focus on indie hosts. It has the goal to completely transform how networking and connectivity are done, to make secure by default and a simple user experience the de facto standard.
- Our path to do this definitely depends on monetising enterprise rather than indiehosters. That said, you can build abstractions on OpenZiti, which are much more simple and focused on indie hosters. A good example is zrok (https://zrok.io/), which makes sharing super simple (publicly, privately, and more), and is built on OpenZiti. Likewise, it's FOSS and permissively licensed under Apache 2.0 while also having a free SaaS.
- Likewise, we truly do believe in the power of app-embedded to transform networking and connectivity, but I would note the majority of people (self-hosters and enterprises alike) today use it as a superior private connectivity platform rather than for the app-embedded. They may use the SDKs, or consider it in the future, but the main selling point is the power of the platform, making it dead simple to do private connectivity across networks while abstracting away a lot of complexity (no need for VPNs, SDWAN, inbound ports, complex ACLs, L4 load balancers, public DNS, etc).
I agree with a lot of what you say. Tbh, this is also why we are advocates of app-embedded ZTNA. You get mTLS (and way, way more) out of the box, without the overhead, and its super easy to run your K8S or non-K8s workloads anywhere. No need for VPNs, inbound FW ports, complex ACLs, L4 loadbalancers, public DNS and more. It is thus much easier to build distributed systems which are secure by default from network attacks.
We are not rolling our own crypto, we use well vetted open source standards/implementations - https://openziti.io/docs/learn/core-concepts/security/connec.... If you don't trust that, you can easily roll your own - https://github.com/openziti/tlsuv/blob/main/README.md. I know people who do that. Yes, its been audited, and run my many large enterprises in security conscious use cases - e.g., 8 of the 10 largest banks, some of the largest defence contractors, leaders in ICS/OT automation as well as grid etc.
Yes, we support K8S in a lot of ways, both for tunnelling and deployement - https://openziti.io/docs/reference/tunnelers/kubernetes/. There are more native options being worked on incl. Admission Controller and Ingress Controller but I honestly don't know the exact status of either. If they interest you, feel free to ping me on philip.griffiths@netfoundry.io. I can get more info.
Similarities: - Fully open source, using CAs as strong identities (rather than relying on SSO from third parties), completely self-hosted (with 3rd party SaaS options), and providing scalable, performant overlay networking.
Differences:
- OpenZiti is focused on connecting services based on zero trust principles. In contrast, Nebula focuses on connecting machines – e.g., you can authorize only a single port without needing to set up ACLs or firewall rules.
- OpenZiti does not require inbound ports or hole punching, it builds outbound only connections via an overlay which looks sort of similar to DERP (but better with app specific encryption, routing, flow control, smart routing etc). This overlay also removes need for complex FW rules, ACLs, public DNS, L4 loadbalancers, etc.
- As alluded to above, truly private, zero trust DNS entries with unique naming – if you wanted to call your service "my.secret.service", you can do that; it does not force you to have a valid Top Level Domain.
- OpenZiti includes SDKs (along with appliance or host based tunnels) to bring overlay networking and zero trust principles directly into your application.
- FOSS Nebula does not include "provisioning new clients with identities", as this person pointed out in our public forum - https://openziti.discourse.group/t/using-openziti-in-distrib...
We took the opposite approach with NetFoundry. (1) We open sourced the code (https://openziti.io/), (2) we built in PKI with private keys generated at source and destination so that even if traversing NF hosted data plane, we CANNOT decrypt traffic, (3) mTLS everywhere, (4) ability to bring your own PKI, and more.
Directly answering your concerns:
- Deny by default and least privilege model means getting access to a node does not give you access to all services on the overlay. This includes SDKs so that only embedded apps are authorised, the apps have no listening ports on underlay and are literally unattackable via conventional IP-based tooling, all conventional network threats are immediately useless.
- Its open source nature means its being adopted by companies to create more powerful ecosystems.
- The overlay, while looking similar to DERP, uses individual service encryption and routing with flow control and smart routing (I know people who get much much better performance as a result).
- Our SDK includes a 'clientless' endpoint for the browser called BrowZer - https://blog.openziti.io/introducing-openziti-browzer. All users need to do it log into their IdP and everything else is done automatically, without involvement from the user.
- We don't build on Wireguard, which provides much more flexibility.
Another option could be zrok (https://zrok.io/), which is an alternative that is open source, and also includes SDKs - https://blog.openziti.io/the-zrok-sdk.
I work on its parent project, OpenZiti, which also may fit your idea. Either way, its a programmatic way to embed connectivity into your app, making it accessible anywhere, but only to people who have authenticated and authorised, its others invisible.
This is a great blog, using Golang as an example - https://blog.openziti.io/go-is-amazing-for-zero-trust.
My favourite quote, "Now, your server has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By adopting an OpenZiti SDK into the server, all conventional network threats are immediately useless."
I will try to remember replying once we do have it.