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“.
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
Stefano Bruno
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.
When using Kibana in environments that require a proxy to reach external services, you might encounter issues with unrecognized SSL certificates. Specifically, if the proxy is exposed with its own certificate and acts as an SSL terminator, requests made by Read More
In a previous post we went through the configuration of Elastic Universal Profiling in NetEye, seeing how we can profile applications written in programming languages that do not compile to native code (for example Python, PHP, Perl, etc.) But what Read More
Elastic 8.16, which comes with NetEye 4.39, made Elastic Universal Profiling generally available for self-hosted installations. This means that NetEye SIEM installations will now be able to take advantage of the continuous profiling solution by Elastic. In this blog post Read More
In the first part of this series, we explored how Jira Service Management (JSM) helps streamline Incident Management, aligning with ITIL v4 best practices. Incident Management aims to restore normal service operation as quickly as possible after a disruption, ensuring Read More
Hello everyone! Today, I'd like to briefly discuss an improvement to the update and upgrade procedures that we've started to adopt with NetEye 4.39! What we wanted to improve One aspect that made quite an impact was that whenever the Read More