This is a question related to the Icinga technology, it is not really a problem.
In the configuration for an agent, the zone to which it belongs has to be declared, together with the satellite(s) that will contact the agent.
Note that this question is limited to the use case where the satellite contacts the agent, and the agent never initiates the connection to the satellite.
Why is it needed to list the satellites without their IP address? What is Icinga doing with this information? Is it checking the identity of the incoming satellite using its certificate, and checking that the name is listed in the zones.conf?
If anyone has insight on this, or just confirms my intuition, I’ll be happy to understand.
I think we have the same “intuition”. But the questions remain: Why is it needed to list the satellites without their IP address (or host name) within the agent’s zones.conf file? Why is the parent zone name not enough? What is Icinga doing with the information of the satellite endpoint names?
Assuming of course we are in the case where the satellite contacts the agent, and the agent never initiates the connection to the satellite.
How else should the agent know, without this, if an other node is to be allowed to send it config and commands and where to send the results of check executions.
OK, this makes sense. Now, the agent, knowing the names of its parents and wanting to validate an incoming connection, how does it check these names? Does it verify the certificate of the connecting party? Or does it do a simple DNS check? Or both? Or something else?
OK great. Can I then install the same certificate on a new satellite? Would the agent be able to realise it is being contacted by a “fake” satellite?
Suppose the following scenario:
sat1 and sat2 defining zone mysat
agent1 with parent mysat
Everything works well, then I take down sat1, replace it with sat3, install sat1 certificate on sat3, and restart with mysat zone containing sat2 and sat3 (pretending to be sat1). Will agent1 be fooled by sat3 pretending to be sat1? Will sat2 be fooled? Will the masters be fooled?
As long as the names in the certificate and the zones.conf file match, yes.
If hostname == endpoint name then I would also give sat3 the same hostname and copy /etc/icinga2 from sat1.
icinga2 --version gives you all the paths, where icinga keeps it’s configuration, states, data etc…
Knowing this, it may be a good idea to - on purpose and from the start - give an abstract name to satellites, so that if you need to migrate your satellites to new servers with new names and new IP addresses, the agents can continue to work with the same configuration file (using the abstract names).