26. 03. 2025
Development, NetEye
11. 03. 2019
Stefano Bruno
Log-SIEM, NetEye
Segregated Multitenancy Monitoring: The Satellite and the Essential Role of the CA-Proxy
In many circumstances, monitoring systems need to be extended to locations where we have no direct control. We can think for instance of a company that provides monitoring services to various customers: each with its own firewalls and each with its own security rules. The deployment of firewall rules from the central monitoring node to the multiple devices to be monitored may be a very difficult task for both stakeholders.
Having a distributed infrastructure would help a lot, both in terms of scalabilityand in making this infrastructure less expensive for the various remote Network teams.
With NetEye it is certainly possible to build the scenario described above, but in this article we will concentrate on describing the ways in which the NetEye Master is able to delegate the role of Certification Authority to its Satellites, for those cases where the Master node does not have direct communication with the agents to be monitored.
The signing of the certificate is important (fundamental, even) since it has the task of securing communication between NetEye and remote nodesusing SSL encryption.
The Satellite will deal with communication with the remote Agent and act as a liaison with the Master node, thus also assuming the role of Certificate Authority Proxy (CA-Proxy).
This functionality is present beginning with version 2.8 of Icinga, and I will now give you a concrete example:
The NetEye Master has a single network card:
The NetEye Satellite instead has two network cards, one on the same network as the NetEye Master and the other on the network class of the Agent to be monitored (and therefore not visible to the Master):
The remote agent has a single network card on the same class as the Satellite:
We can establish communication between the Satellite and Master on port 5665:
But communication between the Agent and Master is not possible:
While the Agent can communicate with the Satellite on port 5665:
The first step is to create a host on NetEye. We will call it linux-agent-satellite, specifying an IP address that does not communicate with the master, and selecting the Cluster Zone satellite:
On the Agent tab, we can verify the generation of the Ticket. We will need it in the next few steps.
At this point, we can configure the remote Agent using the Node Wizard.
We need to specify the FQDN and IP Address of the NetEye Satellitenodes instead of the NetEye Master Node. We already have the ticket number because we have already created the Host.
Once we restart the icinga2 service, we will verify on NetEye that there is communication in the direction Agent > Satellite > Master.
As we can see, the IP that cannot be reached by the NetEye Master is clearly reachable thanks to the Satellite.
As mentioned at the beginning of this article, the functionality that allows the NetEye Satellite to sign the certificate on behalf of the Master is called “CA Proxy“.
Stefano Bruno
Consultant at Würth Phoenix
Dear all, I'm Stefano and I was born in Milano.
Since I was a little boy I've always been fascinated by the IT world. My first approach was with a 286 laptop with a 16 color graphic adapter (the early '90s).
Before joining Würth Phoenix as SI consultant, I worked first as IT Consultant, and then for several years as Infrastructure Project Manager, with a strong knowledge in the global IT scenarios: Datacenter consolidation/migration, VMware, monitoring systems, disaster recovery, backup system.
My various ITIL and TOGAF certification allowed me to be able to cooperate in the writing of many ITSM Processes.
I like to play guitar, soccer and cycling, but... my very passion are my 3 baby and my lovely wife that has always encouraged me and helped me to realize my dreams.
Author
Latest posts by Stefano Bruno
13. 07. 2020
NetEye, Service Management, SLM, Unified Monitoring
ITSM Ticketing Integration with NetEye