Live data from Hacker News

Nebula, Slack's Open Source Global Overlay Network

slack.engineering

11–20 of 71 posts

Re: Nebula, Slack's Open Source Global Overlay Network

#12
This 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.

Re: Nebula, Slack's Open Source Global Overlay Network

#13

This 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?

Re: Nebula, Slack's Open Source Global Overlay Network

#16
post #8

Earlier quoted context omitted.

They may have decided that ZT's encryption isn't proven well enough for their needs. It's also posssible they rejected ZT because they didn't want to use ZT's centralized infrastructure. Two years ago was long before ZT started working on making that optional.

ZT allows you to run your own "Moons", meaning you dont need their infrastructure... bit more config required on the client end, but less reliance on Zerotier....

Moons are going to be deprecated soon and as far as I understand never actually worked how people wanted. I.e. they still needed ZTs root servers, even if you were running your own controller.

To contrast, with Nebula you run your own root(s) (lighthouses) and you don't need a controller because important config (ip, group, hostname) is signed by the same CA.

Re: Nebula, Slack's Open Source Global Overlay Network

#17
post #7

I feel like I don't totally follow how you would set this up for, say, a company that has infra in two cloud providers (but no office network or datacenter or anything)... I think the answer is you set up one or more lighthouses with stable IPs on the public internet, and you make sure all your ephemeral cloud machines have IPs on the public internet? And all your ephemeral cloud machines get RFC-1918 addresses that…

(from a single read of the README and the OP)

I think the answer is that your lighthouse(s) are the only machines that need publicly routable IPs. Your ephemeral cloud machines get any RFC-1918 address you want, with any subnet you want.

Engineers would have Nebula set up on their laptop with a configuration that knows about your lighthouse(s) static IP(s). They use the lighthouses for meeting other nodes, UDP hole punching, etc, but otherwise every connection is peer to peer.

Re: Nebula, Slack's Open Source Global Overlay Network

#18
It 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.

Re: Nebula, Slack's Open Source Global Overlay Network

#19
post #18

It 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.

This is effectively a service mesh implemented directly at the IP layer, integrated with the OS.

Re: Nebula, Slack's Open Source Global Overlay Network

#20

This 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.

Slack has a substantial security team, put Nebula through a 3rd party review, and has been running this in production for two years.
Post reply on HN