@cryptotaxi247 / netdata-1 / commits / 5a1007da9

Consolidate security and privacy documents (#14812)

Chris Akritidis committed Mar 27, 2023 at 10:37 UTC 5a1007da9890df6f1ddc2d197beebdbb1405485e
5 files changed +344 -259
docs/category-overview-pages/reverse-proxies.md
+21 -3
@@ -1,8 +1,9 @@
1 # Running Netdata behind a reverse proxy
2
3 If you need to access a Netdata agent's user interface or API in a production environment we recommend you put Netdata behind
4 -another web server and secure access to the dashboard via SSL and user authentication. A dedicated web server also provides more robustness
5 -and capabilities than the Agent's internal [web server](https://github.com/netdata/netdata/blob/master/web/README.md).
4 +another web server and secure access to the dashboard via SSL, user authentication and firewall rules.
5 +
6 +A dedicated web server also provides more robustness and capabilities than the Agent's [internal web server](https://github.com/netdata/netdata/blob/master/web/README.md).
7
8 We have documented running behind
9 [nginx](https://github.com/netdata/netdata/blob/master/docs/Running-behind-nginx.md),
@@ -13,4 +14,21 @@ We have documented running behind
14 and [H2O](https://github.com/netdata/netdata/blob/master/docs/Running-behind-h2o.md).
15 If you prefer a different web server, we suggest you follow the documentation for nginx and tell us how you did it
16 by adding your own "Running behind webserverX" document.
16 -
17 +
18 +When you run Netdata behind a reverse proxy, we recommend you firewall protect all your Netdata servers, so that only the web server IP will be allowed to directly access Netdata. To do this, run this on each of your servers (or use your firewall manager):
19 +
20 +```sh
21 +PROXY_IP="1.2.3.4"
22 +iptables -t filter -I INPUT -p tcp --dport 19999 \! -s ${PROXY_IP} -m conntrack --ctstate NEW -j DROP
23 +```
24 +
25 +The above will prevent anyone except your web server to access a Netdata dashboard running on the host.
26 +
27 +You can also use `netdata.conf`:
28 +
29 +```
30 +[web]
31 + allow connections from = localhost 1.2.3.4
32 +```
33 +
34 +Of course, you can add more IPs.
docs/category-overview-pages/secure-nodes.md new
+177
@@ -0,0 +1,177 @@
1 +# Secure your nodes
2 +
3 +Netdata is a monitoring system. It should be protected, the same way you protect all your admin apps. We assume Netdata
4 +will be installed privately, for your eyes only.
5 +
6 +Upon installation, the Netdata Agent serves the **local dashboard** at port `19999`. If the node is accessible to the
7 +internet at large, anyone can access the dashboard and your node's metrics at `http://NODE:19999`. We made this decision
8 +so that the local dashboard was immediately accessible to users, and so that we don't dictate how professionals set up
9 +and secure their infrastructures.
10 +
11 +Viewers will be able to get some information about the system Netdata is running. This information is everything the dashboard
12 +provides. The dashboard includes a list of the services each system runs (the legends of the charts under the `Systemd Services`
13 +section), the applications running (the legends of the charts under the `Applications` section), the disks of the system and
14 +their names, the user accounts of the system that are running processes (the `Users` and `User Groups` section of the dashboard),
15 +the network interfaces and their names (not the IPs) and detailed information about the performance of the system and its applications.
16 +
17 +This information is not sensitive (meaning that it is not your business data), but **it is important for possible attackers**.
18 +It will give them clues on what to check, what to try and in the case of DDoS against your applications, they will know if they
19 +are doing it right or not.
20 +
21 +Also, viewers could use Netdata itself to stress your servers. Although the Netdata daemon runs unprivileged, with the minimum
22 +process priority (scheduling priority `idle` - lower than nice 19) and adjusts its OutOfMemory (OOM) score to 1000 (so that it
23 +will be first to be killed by the kernel if the system starves for memory), some pressure can be applied on your systems if
24 +someone attempts a DDoS against Netdata.
25 +
26 +Instead of dictating how to secure your infrastructure, we give you many options to establish security best practices
27 +that align with your goals and your organization's standards.
28 +
29 +- [Disable the local dashboard](#disable-the-local-dashboard): **Simplest and recommended method** for those who have
30 + added nodes to Netdata Cloud and view dashboards and metrics there.
31 +
32 +- [Expose Netdata only in a private LAN](#expose-netdata-only-in-a-private-lan). Simplest and recommended method for those who do not use Netdata Cloud.
33 +
34 +- [Fine-grained access control](#fine-grained-access-control): Allow local dashboard access from
35 + only certain IP addresses, such as a trusted static IP or connections from behind a management LAN. Full support for Netdata Cloud.
36 +
37 +- [Use a reverse proxy (authenticating web server in proxy mode)](#use-an-authenticating-web-server-in-proxy-mode): Password-protect
38 + a local dashboard and enable TLS to secure it. Full support for Netdata Cloud.
39 +
40 +- [Use Netdata parents as Web Application Firewalls](#use-netdata-parents-as-web-application-firewalls)
41 +
42 +- [Other methods](#other-methods) list some less common methods of protecting Netdata.
43 +
44 +## Disable the local dashboard
45 +
46 +This is the _recommended method for those who have connected their nodes to Netdata Cloud_ and prefer viewing real-time
47 +metrics using the War Room Overview, Nodes view, and Cloud dashboards.
48 +
49 +You can disable the local dashboard (and API) but retain the encrypted Agent-Cloud link
50 +([ACLK](https://github.com/netdata/netdata/blob/master/aclk/README.md)) that
51 +allows you to stream metrics on demand from your nodes via the Netdata Cloud interface. This change mitigates all
52 +concerns about revealing metrics and system design to the internet at large, while keeping all the functionality you
53 +need to view metrics and troubleshoot issues with Netdata Cloud.
54 +
55 +Open `netdata.conf` with `./edit-config netdata.conf`. Scroll down to the `[web]` section, and find the `mode =
56 +static-threaded` setting, and change it to `none`.
57 +
58 +```conf
59 +[web]
60 + mode = none
61 +```
62 +
63 +Save and close the editor, then [restart your Agent](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md)
64 +using `sudo systemctl
65 +restart netdata`. If you try to visit the local dashboard to `http://NODE:19999` again, the connection will fail because
66 +that node no longer serves its local dashboard.
67 +
68 +> See the [configuration basics doc](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md) for details on how to find
69 +`netdata.conf` and use
70 +> `edit-config`.
71 +
72 +## Expose Netdata only in a private LAN
73 +
74 +If your organisation has a private administration and management LAN, you can bind Netdata on this network interface on all your servers.
75 +This is done in `Netdata.conf` with these settings:
76 +
77 +```
78 +[web]
79 + bind to = 10.1.1.1:19999 localhost:19999
80 +```
81 +
82 +You can bind Netdata to multiple IPs and ports. If you use hostnames, Netdata will resolve them and use all the IPs
83 +(in the above example `localhost` usually resolves to both `127.0.0.1` and `::1`).
84 +
85 +**This is the best and the suggested way to protect Netdata**. Your systems **should** have a private administration and management
86 +LAN, so that all management tasks are performed without any possibility of them being exposed on the internet.
87 +
88 +For cloud based installations, if your cloud provider does not provide such a private LAN (or if you use multiple providers),
89 +you can create a virtual management and administration LAN with tools like `tincd` or `gvpe`. These tools create a mesh VPN
90 +allowing all servers to communicate securely and privately. Your administration stations join this mesh VPN to get access to
91 +management and administration tasks on all your cloud servers.
92 +
93 +For `gvpe` we have developed a [simple provisioning tool](https://github.com/netdata/netdata-demo-site/tree/master/gvpe) you
94 +may find handy (it includes statically compiled `gvpe` binaries for Linux and FreeBSD, and also a script to compile `gvpe`
95 +on your macOS system). We use this to create a management and administration LAN for all Netdata demo sites (spread all over
96 +the internet using multiple hosting providers).
97 +
98 +## Fine-grained access control
99 +
100 +If you want to keep using the local dashboard, but don't want it exposed to the internet, you can restrict access with
101 +[access lists](https://github.com/netdata/netdata/blob/master/web/server/README.md#access-lists). This method also fully
102 +retains the ability to stream metrics
103 +on-demand through Netdata Cloud.
104 +
105 +The `allow connections from` setting helps you allow only certain IP addresses or FQDN/hostnames, such as a trusted
106 +static IP, only `localhost`, or connections from behind a management LAN.
107 +
108 +By default, this setting is `localhost *`. This setting allows connections from `localhost` in addition to _all_
109 +connections, using the `*` wildcard. You can change this setting using Netdata's [simple
110 +patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md).
111 +
112 +```conf
113 +[web]
114 + # Allow only localhost connections
115 + allow connections from = localhost
116 +
117 + # Allow only from management LAN running on `10.X.X.X`
118 + allow connections from = 10.*
119 +
120 + # Allow connections only from a specific FQDN/hostname
121 + allow connections from = example*
122 +```
123 +
124 +The `allow connections from` setting is global and restricts access to the dashboard, badges, streaming, API, and
125 +`netdata.conf`, but you can also set each of those access lists more granularly if you choose:
126 +
127 +```conf
128 +[web]
129 + allow connections from = localhost *
130 + allow dashboard from = localhost *
131 + allow badges from = *
132 + allow streaming from = *
133 + allow netdata.conf from = localhost fd* 10.* 192.168.* 172.16.* 172.17.* 172.18.* 172.19.* 172.20.* 172.21.* 172.22.* 172.23.* 172.24.* 172.25.* 172.26.* 172.27.* 172.28.* 172.29.* 172.30.* 172.31.*
134 + allow management from = localhost
135 +```
136 +
137 +See the [web server](https://github.com/netdata/netdata/blob/master/web/server/README.md#access-lists) docs for additional details
138 +about access lists. You can take
139 +access lists one step further by [enabling SSL](https://github.com/netdata/netdata/blob/master/web/server/README.md#enabling-tls-support) to encrypt data from local
140 +dashboard in transit. The connection to Netdata Cloud is always secured with TLS.
141 +
142 +## Use an authenticating web server in proxy mode
143 +
144 +Use one web server to provide authentication in front of **all your Netdata servers**. So, you will be accessing all your Netdata with
145 +URLs like `http://{HOST}/netdata/{NETDATA_HOSTNAME}/` and authentication will be shared among all of them (you will sign-in once for all your servers).
146 +Instructions are provided on how to set the proxy configuration to have Netdata run behind
147 +[nginx](https://github.com/netdata/netdata/blob/master/docs/Running-behind-nginx.md),
148 +[HAproxy](https://github.com/netdata/netdata/blob/master/docs/Running-behind-haproxy.md),
149 +[Apache](https://github.com/netdata/netdata/blob/master/docs/Running-behind-apache.md),
150 +[lighthttpd](https://github.com/netdata/netdata/blob/master/docs/Running-behind-lighttpd.md),
151 +[caddy](https://github.com/netdata/netdata/blob/master/docs/Running-behind-caddy.md), and
152 +[H2O](https://github.com/netdata/netdata/blob/master/docs/Running-behind-h2o.md).
153 +
154 +## Use Netdata parents as Web Application Firewalls
155 +
156 +The Netdata Agents you install on your production systems do not need direct access to the Internet. Even when you use
157 +Netdata Cloud, you can appoint one or more Netdata Parents to act as border gateways or application firewalls, isolating
158 +your production systems from the rest of the world. Netdata
159 +Parents receive metric data from Netdata Agents or other Netdata Parents on one side, and serve most queries using their own
160 +copy of the data to satisfy dashboard requests on the other side.
161 +
162 +For more information see [Streaming and replication](https://github.com/netdata/netdata/blob/master/docs/metrics-storage-management/enable-streaming.md).
163 +
164 +## Other methods
165 +
166 +Of course, there are many more methods you could use to protect Netdata:
167 +
168 +- Bind Netdata to localhost and use `ssh -L 19998:127.0.0.1:19999 remote.netdata.ip` to forward connections of local port 19998 to remote port 19999.
169 +This way you can ssh to a Netdata server and then use `http://127.0.0.1:19998/` on your computer to access the remote Netdata dashboard.
170 +
171 +- If you are always under a static IP, you can use the script given above to allow direct access to your Netdata servers without authentication,
172 +from all your static IPs.
173 +
174 +- Install all your Netdata in **headless data collector** mode, forwarding all metrics in real-time to a parent
175 + Netdata server, which will be protected with authentication using an nginx server running locally at the parent
176 + Netdata server. This requires more resources (you will need a bigger parent Netdata server), but does not require
177 + any firewall changes, since all the child Netdata servers will not be listening for incoming connections.
docs/cloud/data-privacy.md deleted
-31
@@ -1,31 +0,0 @@
1 -# Data privacy in Netdata Cloud
2 -
3 -[Data privacy](https://netdata.cloud/privacy/) is very important to us. We firmly believe that your data belongs to
4 -you. This is why **we don't store any metric data in Netdata Cloud**.
5 -
6 -Your local installations of the Netdata Agent form the basis for the Netdata Cloud. All the data that you see in the web browser when using Netdata Cloud, is actually streamed directly from the Netdata Agent to the Netdata Cloud dashboard.
7 -The data passes through our systems, but it isn't stored. You can learn more about [the Agent's security design](https://github.com/netdata/netdata/blob/master/docs/netdata-security.md) in the Agent documentation.
8 -
9 -However, to be able to offer the stunning visualizations and advanced functionality of Netdata Cloud, it does store a limited number of _metadata_.
10 -
11 -## Data Netdata Cloud stores and processes
12 -
13 -Let's look at the metadata Netdata Cloud stores using the publicly available demo server `frankfurt.my-netdata.io`:
14 -
15 -- The email address you used to sign up/or sign in
16 -- For each node connected to your Spaces in Netdata Cloud:
17 - - Hostname (as it appears in Netdata Cloud)
18 - - Information shown in `/api/v1/info`. For example: [https://frankfurt.my-netdata.io/api/v1/info](https://frankfurt.my-netdata.io/api/v1/info).
19 - - Metric metadata information shown in `/api/v1/contexts`. For example: [https://frankfurt.my-netdata.io/api/v1/contexts](https://frankfurt.my-netdata.io/api/v1/contexts).
20 - - Alarm configurations shown in `/api/v1/alarms?all`. For example: [https://frankfurt.my-netdata.io/api/v1/alarms?all](https://frankfurt.my-netdata.io/api/v1/alarms?all).
21 - - Active alarms shown in `/api/v1/alarms`. For example: [https://frankfurt.my-netdata.io/api/v1/alarms](https://frankfurt.my-netdata.io/api/v1/alarms).
22 -
23 -How we use them:
24 -
25 -- The data is stored in our production database on AWS. Some of it is also used in Google BigQuery, our data lake, for analytics purposes. These analytics are crucial for our product development process.
26 -- Email is used to identify users in regards to product use and to enrich our tools with product use, such as our CRM.
27 -- This data is only available to Netdata and never to a 3rd party.
28 -
29 -## Delete all personal data
30 -
31 -To remove all personal info we have about you (email and activities) you need to delete your cloud account by logging into https://app.netdata.cloud and accessing your profile, at the bottom left of your screen.
docs/cloud/pci-soc-hipaa.md deleted
-29
@@ -1,29 +0,0 @@
1 -# PCI DSS, SOC 2 and HIPAA environments
2 -
3 -When running Netdata in environments requiring Payment Card Industry Data Security Standard (PCI DSS), Systems and Organization Controls (SOC 2),
4 -or Health Insurance Portability and Accountability Act (HIPAA) compliance, please keep in mind the following:
5 -
6 -## All collected data is always stored inside your infrastructure
7 -
8 -Even when you use Netdata Cloud, your data is never stored outside your infrastructure. Dashboard data you view and alert notifications do travel
9 -over Netdata Cloud, as they also travel over third party networks, to reach your web browser or the notification integrations you have configured,
10 -but Netdata Cloud does not store metric data. It only transforms them as they pass through it, aggregating them from multiple Agents and Parents,
11 -to appear as one data source on your browser.
12 -
13 -For more information see [Metric Retention - Database](https://github.com/netdata/netdata/blob/master/database/README.md) and
14 -[Data Netdata Cloud Stores and Processes](https://github.com/netdata/netdata/blob/master/docs/cloud/data-privacy.md#data-netdata-cloud-stores-and-processes).
15 -
16 -## Netdata Parents can be used as Web Application Firewalls (WAFs) for accessing your monitoring data
17 -
18 -The Netdata Agents you install on your production systems do not need direct access to the Internet. Even when you use Netdata Cloud, you can appoint
19 -one or more Netdata Parents to act as border gateways or application firewalls, isolating your production systems from the rest of the world. Netdata
20 -Parents receive metric data from Netdata Agents or other Netdata Parents on one side, and serve most queries using their own copy of the data to satisfy
21 -dashboard requests on the other side.
22 -
23 -For more information see [Streaming and replication](https://github.com/netdata/netdata/blob/master/docs/metrics-storage-management/enable-streaming.md).
24 -
25 -[Functions](https://github.com/netdata/netdata/blob/master/docs/cloud/netdata-functions.md) is currently the only feature that routes requests back to
26 -origin Netdata Agents via Netdata Parents. The feature allows Netdata Cloud to send a request to the Netdata Agent data collection plugin running at the
27 -edge, to provide additional information, such as the process tree of a server, or the long queries of a DB.
28 -
29 -<!-- You have full control over the available functions. For more information see “Controlling Access to Functions” and “Disabling Functions”. -->
docs/netdata-security.md
+146 -196
@@ -1,256 +1,184 @@
1 # Security design
2
3 -We have given special attention to all aspects of Netdata, ensuring that everything throughout its operation is as secure as possible. Netdata has been designed with security in mind.
4 -
5 -**Table of Contents**
6 -
7 -- [Your data is safe with Netdata](#your-data-is-safe-with-netdata)
8 -- [Your systems are safe with Netdata](#your-systems-are-safe-with-netdata)
9 -- [Netdata is read-only](#netdata-is-read-only)
10 -- [Why Netdata should be protected](#why-netdata-should-be-protected)
11 -- [Protect Netdata from the internet](#protect-netdata-from-the-internet)
12 -- [Anonymous Statistics](#anonymous-statistics)
13 -- [Netdata directories](#netdata-directories)
14 -
15 -## Your data is safe with Netdata
16 -
17 -Netdata collects raw data from many sources. For each source, Netdata uses a plugin that connects to the source (or reads the relative files produced by the source), receives raw data and processes them to calculate the metrics shown on Netdata dashboards.
18 -
19 -Even if Netdata plugins connect to your database server, or read your application log file to collect raw data, the product of this data collection process is always a number of **chart metadata and metric values** (summarized data for dashboard visualization). All Netdata plugins (internal to the Netdata daemon, and external ones written in any computer language), convert raw data collected into metrics, and only these metrics are stored in Netdata databases, sent to upstream Netdata servers, or archived to external time-series databases.
20 -
21 -> The **raw data** collected by Netdata, does not leave the host when collected. **The only data Netdata exposes are chart metadata and metric values.**
22 -
23 -This means that Netdata can safely be used in environments that require the highest level of data isolation (like PCI Level 1).
24 -
25 -## Your systems are safe with Netdata
26 -
27 -We are very proud that **the Netdata daemon runs as a normal system user, without any special privileges**. This is quite an achievement for a monitoring system that collects all kinds of system and application metrics.
28 -
29 -There are a few cases, however, that raw source data are only exposed to processes with escalated privileges. To support these cases, Netdata attempts to minimize and completely isolate the code that runs with escalated privileges.
30 -
31 -So, Netdata **plugins**, even those running with escalated capabilities or privileges, perform a **hard coded data collection job**. They do not accept commands from Netdata. The communication is strictly **unidirectional**: from the plugin towards the Netdata daemon. The original application data collected by each plugin do not leave the process they are collected, are not saved and are not transferred to the Netdata daemon. The communication from the plugins to the Netdata daemon includes only chart metadata and processed metric values.
32 -
33 -Child nodes use the same protocol when streaming metrics to their parent nodes. The raw data collected by the plugins of
34 -child Netdata servers are **never leaving the host they are collected**. The only data appearing on the wire are chart
35 -metadata and metric values. This communication is also **unidirectional**: child nodes never accept commands from
36 -parent Netdata servers.
37 -
38 -## Netdata is read-only
39 -
40 -Netdata **dashboards are read-only**. Dashboard users can view and examine metrics collected by Netdata, but cannot instruct Netdata to do something other than present the already collected metrics.
41 -
42 -Netdata dashboards do not expose sensitive information. Business data of any kind, the kernel version, O/S version, application versions, host IPs, etc are not stored and are not exposed by Netdata on its dashboards.
43 -
44 -## Why Netdata should be protected
45 -
46 -Netdata is a monitoring system. It should be protected, the same way you protect all your admin apps. We assume Netdata will be installed privately, for your eyes only.
47 -
48 -Upon installation, the Netdata Agent serves the **local dashboard** at port `19999`. If the node is accessible to the
49 -internet at large, anyone can access the dashboard and your node's metrics at `http://NODE:19999`. We made this decision
50 -so that the local dashboard was immediately accessible to users, and so that we don't dictate how professionals set up
51 -and secure their infrastructures.
3 +This document serves as the relevant Annex to the [Terms of Service](http://netdata.cloud/service-terms/) and
4 +the Data Processing Addendum, when applicable. It provides more information regarding Netdata’s technical and organizational security and privacy measures.
5
53 -Viewers will be able to get some information about the system Netdata is running. This information is everything the dashboard provides. The dashboard includes a list of the services each system runs (the legends of the charts under the `Systemd Services` section), the applications running (the legends of the charts under the `Applications` section), the disks of the system and their names, the user accounts of the system that are running processes (the `Users` and `User Groups` section of the dashboard), the network interfaces and their names (not the IPs) and detailed information about the performance of the system and its applications.
54 -
55 -This information is not sensitive (meaning that it is not your business data), but **it is important for possible attackers**. It will give them clues on what to check, what to try and in the case of DDoS against your applications, they will know if they are doing it right or not.
56 -
57 -Also, viewers could use Netdata itself to stress your servers. Although the Netdata daemon runs unprivileged, with the minimum process priority (scheduling priority `idle` - lower than nice 19) and adjusts its OutOfMemory (OOM) score to 1000 (so that it will be first to be killed by the kernel if the system starves for memory), some pressure can be applied on your systems if someone attempts a DDoS against Netdata.
58 -
59 -## Protect Netdata from the internet
60 -
61 -Instead of dictating how to secure your infrastructure, we give you many options to establish security best practices
62 -that align with your goals and your organization's standards.
63 -
64 -- [Disable the local dashboard](#disable-the-local-dashboard): **Simplest and recommended method** for those who have
65 - added nodes to Netdata Cloud and view dashboards and metrics there.
66 -
67 -- [Expose Netdata only in a private LAN](#expose-netdata-only-in-a-private-lan). Simplest and recommended method for those who do not use Netdata Cloud.
68 -
69 -- [Fine-grained access control](#fine-grained-access-control): Allow local dashboard access from
70 - only certain IP addresses, such as a trusted static IP or connections from behind a management LAN. Full support for Netdata Cloud.
71 -
72 -- [Use a reverse proxy (authenticating web server in proxy mode)](#use-an-authenticating-web-server-in-proxy-mode): Password-protect
73 - a local dashboard and enable TLS to secure it. Full support for Netdata Cloud.
74 -
75 -- [Other methods](#other-methods) list some less common methods of protecting Netdata.
76 -
77 -### Disable the local dashboard
6 +We have given special attention to all aspects of Netdata, ensuring that everything throughout its operation is as secure as possible. Netdata has been designed with security in mind.
7
79 -This is the _recommended method for those who have connected their nodes to Netdata Cloud_ and prefer viewing real-time
80 -metrics using the War Room Overview, Nodes view, and Cloud dashboards.
8 +> When running Netdata in environments requiring Payment Card Industry Data Security Standard (**PCI DSS**), Systems and Organization Controls (**SOC 2**),
9 +or Health Insurance Portability and Accountability Act (**HIPAA**) compliance, please keep in mind that
10 +**even when you use Netdata Cloud, all collected data is always stored inside your infrastructure**.
11
82 -You can disable the local dashboard (and API) but retain the encrypted Agent-Cloud link ([ACLK](https://github.com/netdata/netdata/blob/master/aclk/README.md)) that
83 -allows you to stream metrics on demand from your nodes via the Netdata Cloud interface. This change mitigates all
84 -concerns about revealing metrics and system design to the internet at large, while keeping all the functionality you
85 -need to view metrics and troubleshoot issues with Netdata Cloud.
12 +Dashboard data you view and alert notifications do travel
13 +over Netdata Cloud, as they also travel over third party networks, to reach your web browser or the notification integrations you have configured,
14 +but Netdata Cloud does not store metric data. It only transforms them as they pass through it, aggregating them from multiple Agents and Parents,
15 +to appear as one data source on your browser.
16
87 -Open `netdata.conf` with `./edit-config netdata.conf`. Scroll down to the `[web]` section, and find the `mode =
88 -static-threaded` setting, and change it to `none`.
17 +**Table of Contents**
18 +- [Cloud design](#cloud-design)
19 + - [User identification and authorization](#user-identification-and-authorization)
20 + - [Personal Data stored](#personal-data-stored)
21 + - [Infrastructure data stored](#infrastructure-data-stored)
22 + - [Data transfer](#data-transfer)
23 + - [Data retention](#data-retention)
24 + - [Data portability and erasure](#data-portability-and-erasure)
25 +- [Agent design](#agent-design)
26 + - [Your data is safe with Netdata](#your-data-is-safe-with-netdata)
27 + - [Your systems are safe with Netdata](#your-systems-are-safe-with-netdata)
28 + - [Netdata is read-only](#netdata-is-read-only)
29 + - [Protect Netdata from the internet](#protect-netdata-from-the-internet)
30 + - [Anonymous Statistics](#anonymous-statistics)
31 + - [Netdata directories](#netdata-directories)
32 +- [Organization processes](#organization-processes)
33 + - [Employee identification and authorization](#employee-identification-and-authorization)
34 + - [Systems security](#systems-security)
35
90 -```conf
91 -[web]
92 - mode = none
93 -```
36
95 -Save and close the editor, then [restart your Agent](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md) using `sudo systemctl
96 -restart netdata`. If you try to visit the local dashboard to `http://NODE:19999` again, the connection will fail because
97 -that node no longer serves its local dashboard.
37 +## Cloud design
38
99 -> See the [configuration basics doc](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md) for details on how to find `netdata.conf` and use
100 -> `edit-config`.
39 +### User identification and authorization
40
102 -### Expose Netdata only in a private LAN
41 +Netdata ensures that only an email address is stored to create an account and use the Service.
42 +User identification and authorization is done
43 +either via third parties (Google, GitHub accounts), or short-lived access tokens, sent to the user’s email account.
44
104 -If your organisation has a private administration and management LAN, you can bind Netdata on this network interface on all your servers. This is done in `Netdata.conf` with these settings:
45 +### Personal Data stored
46
106 -```
107 -[web]
108 - bind to = 10.1.1.1:19999 localhost:19999
109 -```
47 +Netdata ensures that only an email address is stored to create an account and use the Service. The same email
48 +address is used for Netdata product and marketing communications (via Hubspot and Sendgrid).
49
111 -You can bind Netdata to multiple IPs and ports. If you use hostnames, Netdata will resolve them and use all the IPs (in the above example `localhost` usually resolves to both `127.0.0.1` and `::1`).
50 +Email addresses are stored in our production database on AWS and copied to Google BigQuery, our data lake,
51 +for analytics purposes. These analytics are crucial for our product development process.
52
113 -**This is the best and the suggested way to protect Netdata**. Your systems **should** have a private administration and management LAN, so that all management tasks are performed without any possibility of them being exposed on the internet.
53 +If the user accepts the use of analytical cookies, the email address is also stored in the systems we use to track the
54 +usage of the application (Posthog and Gainsight PX)
55
115 -For cloud based installations, if your cloud provider does not provide such a private LAN (or if you use multiple providers), you can create a virtual management and administration LAN with tools like `tincd` or `gvpe`. These tools create a mesh VPN allowing all servers to communicate securely and privately. Your administration stations join this mesh VPN to get access to management and administration tasks on all your cloud servers.
56 +The IP address used to access Netdata Cloud is stored in web proxy access logs. If the user accepts the use of analytical
57 +cookies, the IP is also stored in the systems we use to track the usage of the application (Posthog and Gainsight PX).
58
117 -For `gvpe` we have developed a [simple provisioning tool](https://github.com/netdata/netdata-demo-site/tree/master/gvpe) you may find handy (it includes statically compiled `gvpe` binaries for Linux and FreeBSD, and also a script to compile `gvpe` on your macOS system). We use this to create a management and administration LAN for all Netdata demo sites (spread all over the internet using multiple hosting providers).
59 +### Infrastructure data stored
60
119 -### Fine-grained access control
61 +The metric data that you see in the web browser when using Netdata Cloud is streamed directly from the Netdata Agent
62 +to the Netdata Cloud dashboard, via the Agent-Cloud link (see [data transfer](#data-transfer)). The data passes through our systems, but it isn’t stored.
63
121 -If you want to keep using the local dashboard, but don't want it exposed to the internet, you can restrict access with
122 -[access lists](https://github.com/netdata/netdata/blob/master/web/server/README.md#access-lists). This method also fully retains the ability to stream metrics
123 -on-demand through Netdata Cloud.
64 +The metadata we do store for each node connected to your Spaces in Netdata Cloud is:
65 + - Hostname (as it appears in Netdata Cloud)
66 + - Information shown in `/api/v1/info`. For example: [https://frankfurt.my-netdata.io/api/v1/info](https://frankfurt.my-netdata.io/api/v1/info).
67 + - Metric metadata information shown in `/api/v1/contexts`. For example: [https://frankfurt.my-netdata.io/api/v1/contexts](https://frankfurt.my-netdata.io/api/v1/contexts).
68 + - Alarm configurations shown in `/api/v1/alarms?all`. For example: [https://frankfurt.my-netdata.io/api/v1/alarms?all](https://frankfurt.my-netdata.io/api/v1/alarms?all).
69 + - Active alarms shown in `/api/v1/alarms`. For example: [https://frankfurt.my-netdata.io/api/v1/alarms](https://frankfurt.my-netdata.io/api/v1/alarms).
70
125 -The `allow connections from` setting helps you allow only certain IP addresses or FQDN/hostnames, such as a trusted
126 -static IP, only `localhost`, or connections from behind a management LAN.
71 +The infrastructure data is stored in our production database on AWS and copied to Google BigQuery, our data lake, for
72 + analytics purposes.
73
128 -By default, this setting is `localhost *`. This setting allows connections from `localhost` in addition to _all_
129 -connections, using the `*` wildcard. You can change this setting using Netdata's [simple
130 -patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md).
74 +### Data transfer
75
132 -```conf
133 -[web]
134 - # Allow only localhost connections
135 - allow connections from = localhost
76 +All infrastructure data visible on Netdata Cloud has to pass through the Agent-Cloud link (ACLK) mechanism, which
77 +securely connects a Netdata Agent to Netdata Cloud. The Netdata agent initiates and establishes an outgoing secure
78 +WebSocket (WSS) connection to Netdata Cloud. The ACLK is encrypted, safe, and is only established if you connect your node.
79
137 - # Allow only from management LAN running on `10.X.X.X`
138 - allow connections from = 10.*
80 +Data is encrypted when in transit between a user and Netdata Cloud using TLS.
81
140 - # Allow connections only from a specific FQDN/hostname
141 - allow connections from = example*
142 -```
82 +### Data retention
83
144 -The `allow connections from` setting is global and restricts access to the dashboard, badges, streaming, API, and
145 -`netdata.conf`, but you can also set each of those access lists more granularly if you choose:
84 +Netdata may maintain backups of Netdata Cloud Customer Content, which would remain in place for approximately thirty
85 +(30) days following a deletion in Netdata Cloud.
86
147 -```conf
148 -[web]
149 - allow connections from = localhost *
150 - allow dashboard from = localhost *
151 - allow badges from = *
152 - allow streaming from = *
153 - allow netdata.conf from = localhost fd* 10.* 192.168.* 172.16.* 172.17.* 172.18.* 172.19.* 172.20.* 172.21.* 172.22.* 172.23.* 172.24.* 172.25.* 172.26.* 172.27.* 172.28.* 172.29.* 172.30.* 172.31.*
154 - allow management from = localhost
155 -```
87 +### Data portability and erasure
88
157 -See the [web server](https://github.com/netdata/netdata/blob/master/web/server/README.md#access-lists) docs for additional details about access lists. You can take
158 -access lists one step further by [enabling SSL](https://github.com/netdata/netdata/blob/master/web/server/README.md#enabling-tls-support) to encrypt data from local
159 -dashboard in transit. The connection to Netdata Cloud is always secured with TLS.
89 +Netdata will, as necessary to enable the Customer to meet its obligations under Data Protection Law, provide the Customer
90 +via the availability of Netdata Cloud with the ability to access, retrieve, correct and delete the Personal Data stored in
91 +Netdata Cloud. The Customer acknowledges that such ability may from time to time be limited due to temporary service outages
92 +for maintenance or other updates to Netdata Cloud, or technically not feasible.
93
161 -### Use an authenticating web server in proxy mode
94 +To the extent that the Customer, in its fulfillment of its Data Protection Law obligations, is unable to access, retrieve,
95 +correct or delete Customer Personal Data in Netdata Cloud due to prolonged unavailability of Netdata Cloud due to an issue
96 +within Netdata’s control, Netdata will where possible use reasonable efforts to provide, correct or delete such Customer Personal Data.
97
163 -Use one web server to provide authentication in front of **all your Netdata servers**. So, you will be accessing all your Netdata with URLs like `http://{HOST}/netdata/{NETDATA_HOSTNAME}/` and authentication will be shared among all of them (you will sign-in once for all your servers). Instructions are provided on how to set the proxy configuration to have Netdata run behind
164 -[nginx](https://github.com/netdata/netdata/blob/master/docs/Running-behind-nginx.md),
165 -[HAproxy](https://github.com/netdata/netdata/blob/master/docs/Running-behind-haproxy.md),
166 -[Apache](https://github.com/netdata/netdata/blob/master/docs/Running-behind-apache.md),
167 -[lighthttpd](https://github.com/netdata/netdata/blob/master/docs/Running-behind-lighttpd.md),
168 -[caddy](https://github.com/netdata/netdata/blob/master/docs/Running-behind-caddy.md), and
169 -[H2O](https://github.com/netdata/netdata/blob/master/docs/Running-behind-h2o.md).
98 +If a Customer is unable to delete Personal Data via the self-services functionality, then Netdata deletes Personal Data upon
99 +the Customer’s written request, within the timeframe specified in the DPA and in accordance with applicable data protection law.
100
171 -To use this method, you should firewall protect all your Netdata servers, so that only the web server IP will be allowed to directly access Netdata. To do this, run this on each of your servers (or use your firewall manager):
101 +#### Delete all personal data
102
173 -```sh
174 -PROXY_IP="1.2.3.4"
175 -iptables -t filter -I INPUT -p tcp --dport 19999 \! -s ${PROXY_IP} -m conntrack --ctstate NEW -j DROP
176 -```
103 +To remove all personal info we have about you (email and activities) you need to delete your cloud account by logging into https://app.netdata.cloud and accessing your profile, at the bottom left of your screen.
104
178 -*commands to allow direct access to Netdata from a web server proxy*
105
180 -The above will prevent anyone except your web server to access a Netdata dashboard running on the host.
106 +## Agent design
107
182 -For Netdata v1.9+ you can also use `netdata.conf`:
108 +### Your data is safe with Netdata
109
184 -```
185 -[web]
186 - allow connections from = localhost 1.2.3.4
187 -```
110 +Netdata collects raw data from many sources. For each source, Netdata uses a plugin that connects to the source (or reads the
111 +relative files produced by the source), receives raw data and processes them to calculate the metrics shown on Netdata dashboards.
112
189 -Of course you can add more IPs.
113 +Even if Netdata plugins connect to your database server, or read your application log file to collect raw data, the product of
114 +this data collection process is always a number of **chart metadata and metric values** (summarized data for dashboard visualization).
115 +All Netdata plugins (internal to the Netdata daemon, and external ones written in any computer language), convert raw data collected
116 +into metrics, and only these metrics are stored in Netdata databases, sent to upstream Netdata servers, or archived to external
117 +time-series databases.
118
191 -For Netdata prior to v1.9, if you want to allow multiple IPs, use this:
119 +The **raw data** collected by Netdata does not leave the host when collected. **The only data Netdata exposes are chart metadata and metric values.**
120
193 -```sh
194 -# space separated list of IPs to allow access Netdata
195 -NETDATA_ALLOWED="1.2.3.4 5.6.7.8 9.10.11.12"
196 -NETDATA_PORT=19999
121 +This means that Netdata can safely be used in environments that require the highest level of data isolation (like PCI Level 1).
122
198 -# create a new filtering chain || or empty an existing one named netdata
199 -iptables -t filter -N netdata 2>/dev/null || iptables -t filter -F netdata
200 -for x in ${NETDATA_ALLOWED}
201 -do
202 - # allow this IP
203 - iptables -t filter -A netdata -s ${x} -j ACCEPT
204 -done
123 +### Your systems are safe with Netdata
124
206 -# drop all other IPs
207 -iptables -t filter -A netdata -j DROP
125 +We are very proud that **the Netdata daemon runs as a normal system user, without any special privileges**. This is quite an
126 +achievement for a monitoring system that collects all kinds of system and application metrics.
127
209 -# delete the input chain hook (if it exists)
210 -iptables -t filter -D INPUT -p tcp --dport ${NETDATA_PORT} -m conntrack --ctstate NEW -j netdata 2>/dev/null
128 +There are a few cases, however, that raw source data are only exposed to processes with escalated privileges. To support these
129 +cases, Netdata attempts to minimize and completely isolate the code that runs with escalated privileges.
130
212 -# add the input chain hook (again)
213 -# to send all new Netdata connections to our filtering chain
214 -iptables -t filter -I INPUT -p tcp --dport ${NETDATA_PORT} -m conntrack --ctstate NEW -j netdata
215 -```
131 +So, Netdata **plugins**, even those running with escalated capabilities or privileges, perform a **hard coded data collection job**.
132 +They do not accept commands from Netdata. The communication is **unidirectional** from the plugin towards the Netdata daemon, except
133 +for Functions (see below). The original application data collected by each plugin do not leave the process they are collected, are
134 +not saved and are not transferred to the Netdata daemon. The communication from the plugins to the Netdata daemon includes only chart
135 +metadata and processed metric values.
136
217 -_script to allow access to Netdata only from a number of hosts_
137 +Child nodes use the same protocol when streaming metrics to their parent nodes. The raw data collected by the plugins of
138 +child Netdata servers are **never leaving the host they are collected**. The only data appearing on the wire are chart
139 +metadata and metric values. This communication is also **unidirectional**: child nodes never accept commands from
140 +parent Netdata servers (except for Functions).
141
219 -You can run the above any number of times. Each time it runs it refreshes the list of allowed hosts.
142 +[Functions](https://github.com/netdata/netdata/blob/master/docs/cloud/netdata-functions.md) is currently
143 +the only feature that routes requests back to origin Netdata Agents via Netdata Parents. The feature allows Netdata Cloud to send
144 +a request to the Netdata Agent data collection plugin running at the
145 +edge, to provide additional information, such as the process tree of a server, or the long queries of a DB.
146
221 -### Other methods
147 +<!-- You have full control over the available functions. For more information see “Controlling Access to Functions” and “Disabling Functions”. -->
148
223 -Of course, there are many more methods you could use to protect Netdata:
149 +### Netdata is read-only
150
225 -- Bind Netdata to localhost and use `ssh -L 19998:127.0.0.1:19999 remote.netdata.ip` to forward connections of local port 19998 to remote port 19999. This way you can ssh to a Netdata server and then use `http://127.0.0.1:19998/` on your computer to access the remote Netdata dashboard.
151 +Netdata **dashboards are read-only**. Dashboard users can view and examine metrics collected by Netdata, but cannot
152 +instruct Netdata to do something other than present the already collected metrics.
153
227 -- If you are always under a static IP, you can use the script given above to allow direct access to your Netdata servers without authentication, from all your static IPs.
154 +Netdata dashboards do not expose sensitive information. Business data of any kind, the kernel version, O/S version,
155 +application versions, host IPs, etc. are not stored and are not exposed by Netdata on its dashboards.
156
229 -- Install all your Netdata in **headless data collector** mode, forwarding all metrics in real-time to a parent
230 - Netdata server, which will be protected with authentication using an nginx server running locally at the parent
231 - Netdata server. This requires more resources (you will need a bigger parent Netdata server), but does not require
232 - any firewall changes, since all the child Netdata servers will not be listening for incoming connections.
157 +### Protect Netdata from the internet
158
234 -## Anonymous statistics
159 +Users are responsible to take all appropriate measures to secure their Netdata agent installations and especially the Netdata web user interface and API against unauthorized access. Netdata comes with a wide range of options to
160 +[secure your nodes](https://github.com/netdata/netdata/blob/master/docs/category-overview-pages/secure-nodes.md) in
161 +compliance with your organization's security policy.
162
236 -### Registry or how to not send any information to a third party server
163 +### Anonymous statistics
164
238 -The default configuration uses a public registry under registry.my-netdata.io (more information about the registry here: [mynetdata-menu-item](https://github.com/netdata/netdata/blob/master/registry/README.md) ). Please be aware that if you use that public registry, you submit the following information to a third party server:
165 +#### Netdata registry
166
240 -- The url where you open the web-ui in the browser (via http request referrer)
241 -- The hostnames of the Netdata servers
167 +The default configuration uses a public [registry](https://github.com/netdata/netdata/blob/master/registry/README.md) under registry.my-netdata.io.
168 +If you use that public registry, you submit the following information to a third party server:
169 + - The URL of the agent's web user interface (via http request referrer)
170 + - The hostnames of your Netdata servers
171
243 -If sending this information to the central Netdata registry violates your security policies, you can configure Netdata to [run your own registry](https://github.com/netdata/netdata/blob/master/registry/README.md#run-your-own-registry).
172 +If sending this information to the central Netdata registry violates your security policies, you can configure Netdata to
173 +[run your own registry](https://github.com/netdata/netdata/blob/master/registry/README.md#run-your-own-registry).
174
245 -### Opt-out of anonymous statistics
175 +#### Anonymous telemetry events
176
177 Starting with v1.30, Netdata collects anonymous usage information by default and sends it to a self hosted PostHog instance within the Netdata infrastructure. Read
248 -about the information collected, and learn how to-opt, on our [anonymous telemetry events](https://github.com/netdata/netdata/blob/master/docs/anonymous-statistics.md) page.
249 -
250 -The usage statistics are _vital_ for us, as we use them to discover bugs and prioritize new features. We thank you for
251 -_actively_ contributing to Netdata's future.
178 +about the information collected and learn how to opt-out, on our
179 +[anonymous telemetry events](https://github.com/netdata/netdata/blob/master/docs/anonymous-statistics.md) page.
180
253 -## Netdata directories
181 +### Netdata directories
182
183 | path|owner|permissions|Netdata|comments|
184 |:---|:----|:----------|:------|:-------|
@@ -261,4 +189,26 @@ _actively_ contributing to Netdata's future.
189 | `/var/lib/netdata`|user `netdata`<br/>group `netdata`|dirs `0750`<br/>files `0660`|reads, writes, creates, deletes|**Netdata permanent database files**<br/>Netdata stores here the registry data, health alarm log db, etc.|
190 | `/var/log/netdata`|user `netdata`<br/>group `root`|dirs `0755`<br/>files `0644`|writes, creates|**Netdata log files**<br/>all the Netdata applications, logs their errors or other informational messages to files in this directory. These files should be log rotated.|
191
192 +## Organization processes
193 +
194 +### Employee identification and authorization
195 +
196 +Netdata operates technical and organizational measures for employee identification and authentication, such as logs, policies,
197 +assigning distinct usernames for each employee and utilizing password complexity requirements for access to all platforms.
198 +
199 +The COO or HR are the primary system owners for all platforms and may designate additional system owners, as needed. Additional
200 +user access is also established on a role basis, requires the system owner’s approval, and is tracked by HR. User access to each
201 +platform is subject to periodic review and testing. When an employee changes roles, HR updates the employee’s access to all systems.
202 +Netdata uses on-boarding and off-boarding processes to regulate access by Netdata Personnel.
203 +
204 +Second-layer authentication is employed where available, by way of multi-factor authentication.
205 +
206 +Netdata’s IT control environment is based upon industry-accepted concepts, such as multiple layers of preventive and detective
207 +controls, working in concert to provide for the overall protection of Netdata’s computing environment and data assets.
208 +
209 +### Systems security
210
211 +Netdata maintains a risk-based assessment security program. The framework for Netdata’s security program includes administrative,
212 +organizational, technical, and physical safeguards reasonably designed to protect the services and confidentiality, integrity,
213 +and availability of user data. The program is intended to be appropriate to the nature of the services and the size and complexity
214 +of Netdata’s business operations.