A wikipage on "Who uses Netdata" ?

[kmonsoor]

Can we have a page that will show the organizations or companies who are using Netdata in their production environment ?

For example:

• Go language : https://github.com/golang/go/wiki/GoUsers
• Django : https://www.djangoproject.com/start/overview/
• InfluxDB : https://www.influxdata.com/customers/use-cases/

A similar page for Netdata would definitely help the newcomers to be convinced, and also help them to convince non-tech management to authorize its deployment in production.

[ktsaou]

Of course. Nice idea. That page will be empty though initially. So, it will be missleading...
Do you have any ideas how to collect this information?

[kmonsoor]

awesome.
I don't know what works as Netdata's official discussion channel, my ignorance of course. Where its users discuss things that don't fit into as "issue"? For example, some projects uses Gitter, Google groups, #freenode etc. Considering its popularity, and future potential it should have one. IMO, of course. :)
Or, at least, Netdata is on Twitter.

Anyways, after creating the blank page, its Twitter account can issue a public collaboration "notice" to add users' respective use-cases in production. You, and other contributors (+ followers) can propagate ("re-tweet") the "cause". That, I think, it will gather some user companies, at least. Then, at least the page won't be empty. :)

Do Firehol or VivaWallet.com, as a company, use Netdata in production? Then, please go ahead and add it. Kind of like "charity begins at home". Ha ha. I will add my company, too.

I hope best that someday the list grows enormously.

[GPegel]

This idea is really great but... I'm using it also and I love it and yes it is really great. But the reason why I'm not going public with NetData is due to a lack of authentication. I know it will be there in the future but as long as it is not there, I'm not going to show my NetData to the world. And I think this is the case for most of the companies.

[kmonsoor]

@GPegel your concern is real. Highly appreciate your feedback.
However, your instances shouldn't be that open so that whoever knows company-name be able to start poking Netdata. ;)
For example, my (our) setup is using IP-whitelisting, VPC-only access, and different port-number than default etc. measures as basic line-of-defence. Of course, YMMV.

[GPegel]

@kmonsoor I know, you are right but that is indeed a ultra basic line of defense. And in my case, our security officer won't be happy until authentication will be available. But in the mean time, I keep getting my colleagues jealous with those nice metrics ;-)

[ktsaou]

Well, basic authentication in netdata will not solve the problem. A lot more are needed.

But, let me ask this: you need to use netdata privately, for your sysadmins/devops only. Why is that a problem for you?

I mean, there are so many alternatives:

1. If you really need HTTP authentication, proxy all your netdata through an apache, nginx, lighttpd, with authentication and SSL - the wiki has examples for nginx, apache, lighttpd, etc.
2. If you have a DMZ, set up the proper rules at the firewall to allow only your IPs access it.
3. If you have everything on cloud providers, setup gvpe or tinc to create a mesh virtual private netwrok among all your servers. For gvpe I recently developed a nice wrapper to provision everything automatically.
4. If you are unable to use any of the above, you can configure netdata on all your servers to work headless (without listening on any port) and stream all metrics in real-time to a dedicated host, with proper access control to access all the dashboards.
5. If you are still unable to use any of the above, tunnel netdata through ssh. So for a user to access netdata, an open ssh session to the server will be required.

So, yes, netdata should support authentication, but there are so many alternatives...

Could someone explain why is the lack of embedded authentication such a problem?

In general, I follow these rules when I run public servers:

1. Each server must run a firewall (I use FireHOL - my tool too).
2. Each server must run QoS (I use FireQoS - my tool too).
3. Each server must have a private network (VPN for cloud servers, or a second ethernet for physical servers), for all management tasks (this is why I wrote the gvpe provisioning wrapper).
4. Each server must be fully monitored, remotely, without requiring ssh access (this is why I started netdata).
5. Management applications must never be directly exposed to the internet, with or without authentication.
6. Applications with direct access to backends must not be directly exposed to the internet, with or without authentication. There should be another layer 7 application directly exposed (session border controller, web application firewall, proxy of some kind, etc) and this exposed application must not have any direct access to backend systems (e.g. databases).
7. servers must not be allowed to initiate connections towards the internet, except O/S updates and a few whitelisted services (like VPNs, etc) and whenever possible pass even these through a proxy (i.e. a squid for O/S updates, or outgoing web requests).

I am a security freak myself, but I really don't understand why the lack of embedded authentication is a security concern.

So, please help me understand. If you have valid points, I may re-arrange my to-do list to bring authentication at the top...

[GPegel]

At first, company policy. Second, we are working with private customer data over different physical company locations. That's why ;-)

[ktsaou]

At first, company policy. Second, we are working with private customer data over different physical company locations. That's why ;-)

With all the respect, this is not good enough.

• You should not be working on customer private data over the internet, without a certificate based VPN or SSH certificates.
• The customer should not expose its data to its sub-contractors over the internet with a simple username/password authenitcation.

The most basic rule is that you need 2 of the following 3 to get access to customer private data:

1. Something you know (e.g. username/password)
2. Something you have (e.g. a certificate, or OTP to your mobile phone)
3. Something you are (e.g. biometrics, fingerprints, or whatever else)

I am not trying to play it smart here. Plain username/password authentication over the internet is just not secure. So, your policy is probably incomplete if it requires just this to accept a solution as secure.

Think it like that: let's assume we have authentication to netdata and you expose it to the internet. What will limit brute force attacks against it? What will limit customer A of yours find your username and password and use it on customer B netdata?

If you had a certificate based VPN in place, or even SSH certificates, netdata without authentication but restricted to be used over these channels, is pretty secure (since netdata does not expose any customer sensitive data) and a lot more secure compared to username/password authentication over the internet...

[toastbrotch]

even after fulfilling all points discussed here your netdata ui possibly leaks information about you and your setup to thirdparty if you do not run one node as your own private registry.

so add another rule to your list:
check with your browser/tcpdump where your tools talks and what information they expose to thirdparty, possibly even without telling you

since netdata does not expose any customer sensitive data

is correct, but netdata-ui leaks data about you and possibly your netdata urls (if you do not run your own registry)

[ktsaou]

The registry is not something netdata talks to. Only your browser talks to it. It is all documented at the my-netdata "What is this?" menu entry.

We provide a default registry so that alarm notifications links will work, integration between netdata servers will work, etc. All users can configure their own.

We have discussed this extensively at #3937 and #2760 since you had concerns that the registry is leaking personal data. As I told you there, the registry is not maintaining any personal data, the data are not sensitive, and there is no reason to opt-in. Users can opt-out by installing their own registry.

[toastbrotch]

there are environments where you dont want your internal/private admin-tools/web-uis submit your browsers ip nor the urls where you have those web-uis hosted, to a thirdparty server. this might be sensitive data and this declaration is not done by you, but the internal policies. i don't understand why you refuse to accept this.

and i see nothing stated here at all about this communication between your browser and the registry: https://github.com/firehol/netdata/wiki/netdata-security . its not stated there that you send your browsers IP and all the urls you run your netdata web-uis to a thirdpartyserver (independent of what the operator of this does with those data) if you do not run your own registry. in my opinion you cut out an important fact.

[Ferroin]

@ktsaou I'm inclined to agree with @toastbrotch about the netdata-swcurity wiki page. It should absolutely document that you need to configure a private registry if you don't want to send anything outside your network. Companies where things like internal hostnames are considered sensitive data do exist (I work for one currently).

[ktsaou]

ok, folks, just edit that page.

I work for such a company too and we use our own registry.
I am not trying to hide how the registry works. I just don't think netdata should be shipped without one.

[paulfantom]

Discussion went highly off topic here. I am against creating such page, but I am in favor of having something like "User testimonials" on some sort of a blog.

[paulfantom]

Closing issue due to inactivity. Please reopen if this is still relevant.