Netdata Community

Remove Account Linking

Feature Requests Netdata Agent Feature Requests
#1

This Feature Request was posted on GitHub: Account Linking is harmful and is a Non-Feature · Issue #10497 · netdata/netdata · GitHub

Account Linking is harmful and is a Non-Feature

I have multiple (20+) agents sending streams to central server. All health notification are sent from that server only. I do not use cloud services.

During several upgrades, I’ve noticed different issues that could be easily fixed by doping old time series on the central server. So this is my default upgrade practice now: Drop data, restart central server, everything is working. But there is one problem: All links in the notifications are broken due to account linking and I have to visit every single node again to make it work.

Sorry... your account is not linked to a netdata server named: 
agent.example.com

Notification links like https://netdata.example.com/goto-host-from-alarm.html?host=agent.example.com are handled differently than https://netdata.example.com/host/agent.example.com and it makes no sense since everyone can just rewrite the URL. This is pseudo-security and is actually harming the security by providing a false sense of it.

What account is it anyway? I’ve tried to find some agent documentation on it, but was not successful. How am I supposed to explain to my boss that he can not click on the critical notification, because his non existent “account” is “not linked” and he just need to rewrite the link from time to time on his mobile?

Account Linking should be removed entirely because:

  • the are no accounts
  • the are no security benefits
  • it provides false security sense
  • it leads to bad user experience
#2

Hi there. This isn’t a security feature, but a way to send different people who may be seeing the agent the alarm originated from via different URLs, or even the same person seeing in one URL when inside their company VPN and another when on a public network. The main challenge is that the agent doesn’t necessarily know what URL you use to access it, but your browser definitely does. I know we haven’t explained how this all works so let me describe it here and we really should get our documentation updated:

The “account” mentioned here used to be the registry “person”. A unique identifier that really just identified a browser. When we stopped sending URLs to the public netdata registry due to security concerns, the only redirect we could support on our side was via netdata cloud, and that works only if you’re signed it to the cloud. You can still utilize the legacy behavior that doesn’t use the cloud, by running your own registry.

Both the legacy, registry-based and the newer, cloud-based methods use the same algorithm. They see what URLs “you” (i.e. either your cookie-based “person” for the registry or your cloud account for the other method) have used in the past to access the specific machine that generated the alarm and redirect you to the first reachable URL in that list.

If you are already running your own registry , you can still wipe the timeseries DB if that’s what you want and keep the registry DB (just one file, really). They are stored in different directories.

I hope this has helped to clarify things a bit.