Sounds like a service mesh. How is this any difference to Istio/linkerd? This library may be useful, but the stated problem it seeks to solve is hardly a unique one.
Nebula, Slack's Open Source Global Overlay Network
51–60 of 71 posts
Re: Nebula, Slack's Open Source Global Overlay Network
#52This is a really cool project That being said the code is full of TODO and other comments indicating that shortcuts were taken which should be fixed later. I would be worried about running such a thing in prod given the criticality of its function. At best you could risk performance issues under load and at worst you could have significant security issues allowing unintended traffic in/out.
Do you think it's unusual for businesses to deploy to production code which has TODO statements?
Depends on the TODO statements themselves. "TODO: document this section better" is a huge difference from "TODO: add error handling to this section"
Re: Nebula, Slack's Open Source Global Overlay Network
#53Earlier quoted context omitted.
When your Kubernetes falls over, you can ssh to it and run commands like it's 2003 (or 1993). When your network falls over, not so much. We deprecated our network virtualization at $work and have been way happier for it. Also, the end-to-end principle argues for putting complicated logic in the endpoints and making the network boring. See also, TCP is implemented at the endpoints and just requires network infrastruct…
Part of the reason for the end-to-end argument is to enable more clever (or, at least, more purpose-designed) functionality to ride on top of the dumb network. So e2e would suggest (to my reading at least) that you keep the "real" IP layer dumb and flexible, and do the fun stuff in overlays, which is what this is.
It's also mostly about two rather than N endpoints. The later, follow-on Blumenthal & Clark paper is a kind of long list of end-to-end-principle analysis 'it's complicated's.
Re: Nebula, Slack's Open Source Global Overlay Network
#54It feels like their issues would have been solved by a service mesh using e.g. consul or istio. If so, I'd wonder writing a tool from scratch was the right use of engineering time. Anyway, as an engineer, I'd certainly have found this a fun project. Kudos to slack for trying something new and open sourcing it.
Not entirely as it only really allows stuff thats running in that service mesh's world to connect to the network. But they want a global VPN for _everything_ including laptops. This means some level of access control. What I like here is the use of lighhouses, to allow external nodes to punch in and discover the rest of the network. Something which is very difficult to do if you are relying on a service mesh in an un…
How does this differ from cjdns?
Re: Nebula, Slack's Open Source Global Overlay Network
#55Sounds like a service mesh. How is this any difference to Istio/linkerd? This library may be useful, but the stated problem it seeks to solve is hardly a unique one.
To me it reads more like Nebula is a VPN solution, with end-to-end encryption and security groups baked in.
To my understanding, a service mesh does not establish a common VPN-like network, but assumes it's there already. Nebula and service meshes both provide authentication, end-to-end encryption and role-based access control. A service mesh can do more than Nebula: it makes it possible to shift traffic between services for example apart from a "security group"-like filtering.
However, I might be mistaken. Any corrections are more than welcome.
Re: Nebula, Slack's Open Source Global Overlay Network
#56This does look really great! Is there ipv6 support? Both for overlay network[1], and/or for nodes? [1] https://github.com/slackhq/nebula/issues/6
The answer is no.
Re: Nebula, Slack's Open Source Global Overlay Network
#57Earlier quoted context omitted.
Not entirely as it only really allows stuff thats running in that service mesh's world to connect to the network. But they want a global VPN for _everything_ including laptops. This means some level of access control. What I like here is the use of lighhouses, to allow external nodes to punch in and discover the rest of the network. Something which is very difficult to do if you are relying on a service mesh in an un…
How does this differ from cjdns?
I suspect that the goals are slightly different.
The thing that immediately stands out is the routing. It looks like cjdns is a traditional-ish multi-hop network. The DHT routing table allows you to map out a route to peer A via peer B, R, & D.
What wireguard and nebula allow is for the underlying network to figure out most of the routing, and effectively create a massive point to-point network. whilst you can have concentrators/gateways, the idea is that most of the traffic goes direct from peer to peer. This can reduce load considerably.
Re: Nebula, Slack's Open Source Global Overlay Network
#58Earlier quoted context omitted.
I'm not judging, I'm simply relating a fact: Nebula is MIT licensed, and ZeroTier is BSL'd; a paid license is required to use ZeroTier in a closed-source application.
Yes, that's intentional. It used to be GPL which imposed the same requirement, but we shifted to BSL because it's a bit more explicit and because of (again, irrational) GPL-phobia on the part of some non-trivial subset of corporate users. BTW the closed source restriction in the BSL is effectively the same as the GPL and the only other meaningful restriction is on SaaS direct monetization. Companies can still run ZT…
This is not true. AGPL allows SaaS monetization (you just need to publish the source). BSL does not allow it.
Re: Nebula, Slack's Open Source Global Overlay Network
#59Earlier quoted context omitted.
Yes, that's intentional. It used to be GPL which imposed the same requirement, but we shifted to BSL because it's a bit more explicit and because of (again, irrational) GPL-phobia on the part of some non-trivial subset of corporate users. BTW the closed source restriction in the BSL is effectively the same as the GPL and the only other meaningful restriction is on SaaS direct monetization. Companies can still run ZT…
This is not true. AGPL allows SaaS monetization (you just need to publish the source). BSL does not allow it.
That's why the BSL exists: to stop SaaS companies from monetizing the software without giving anything back to its developers.
A SaaS company can get a commercial license.
Re: Nebula, Slack's Open Source Global Overlay Network
#60How does this differ from WireGuard?
WireGuard is a VPN, and Nebula is an overlay network (also known as a service mesh). They are closely related concepts. VPNs are primarily used for remote access, to get random machines access to closed IP networks. Service meshes synthesize a new network (sometimes IP, sometimes something else) to connect a bunch of related machines, almost always with policy controls for who can talk to what, usually cryptographic.…
Why do you think it is "weird" to use WireGuard for connecting application server with a DB instance?
(Backdrop: I have recently moved our various prod servers into a WireGuard based VPN to encrypt the traffic between them. I found it was easier/pragmatic to do this than:
* to setup SSL for my DB
* to figure out how to encrypt traffic between my application server and Redis or my application server and Nginx )