02. 04. 2020 Damiano Chini NetEye

Tornado Communication over NATS

Until the NetEye 4.10 release, the Tornado module inside NetEye handled communications between its components (the Tornado Collectors and the Tornado Engine) via direct, clear-text TCP connections.

On local systems, this configuration does not represent a limitation, since in this case there is no requirement to verify the identity of the peer (it is always known) and to encrypt messages that are only sent locally. But when Tornado Collectors and the Engine are deployed on systems that are potentially remote, for obvious reasons this configuration raises some issues related to the integrity and confidentiality of the information exchanged by Tornado Collectors and the Engine.

Moreover, in multi-tenant systems, where sensitive data from different organizations passes through Tornado, it is desirable to have control over who can read the different data that does go through.

These reasons led us to the decision to integrate the NATS messaging system into Tornado, which grants security and high performance to these communications.

The NATS server manages communications between the Tornado components with a publish-subscribe pattern, which means that if a sender publishes a message belonging to a subject X, then only those subscribed to subject X will receive that message. Of course NATS also provides ways to configure which client can publish and/or subscribe to the different subjects. This enables us to have control over shared information in multi-tenancy scenarios within Tornado.

The Tornado Engine and Tornado Collectors now communicate with the NATS server over TLS and authenticate to NATS with different certificates, so that we can configure proper publish/subscribe authorizations in NATS for each Tornado component.

In a potential use case where Tornado Collectors need to run on remote nodes with respect to the Tornado Engine, a simple and safe architecture for the remote communication can then be the one below, with the NATS server residing on the node where the Tornado Engine runs, and remote Tornado Collectors communicating directly with the NATS server over TLS.