I have some questions on the security implications of some Icinga2 cluster features. The security section of the distributed monitoring chapter in the Icinga2 documentation lists config sync and remote command endpoint execution as disabled by default for security reasons.
So first of all, there are two basic modes of operation (for simplicity I’m not considering satellites or multiple masters for now):
- In command endpoint mode, all the check scheduling happens on the master. The Icinga2 node on the clients is only executing checks as instructed to by the master. As the docs mention that the CheckCommands have to be defined on the client, I assume that the master sends a reference to a specific CheckCommand together with a list of variables to the client, which then assembles a command line according to the CheckCommand definition, executes it and reports back the result. The client itself does not know of the services actually defined (apart from what can be observed from the commands executed).
- In config sync mode, all the host and service definitions relevant for a client get synced to it. The client itself then schedules the check executions and reports the results back to the master.
The exact behavior of the clients is configured by the accept_commands and accept_config options of the ApiListener:
accept_commands = true, the master can execute any command that matches a CheckCommand definition as the user Icinga2 is running as on the client, including things like probing hosts using check_ping, make arbitrary HTTP requests around the network with check_http, querying network equipment with check_snmp, etc.
accept_config = true, the master can push arbitrary configuration to the client, including arbitrary new CheckCommand and Service object, thus allowing the execution of arbitrary commands on the client as the Icinga2 user, leading to every admins favorite nightmare: opening the possibility to compromise the complete infrastructure by compromising the monitoring server.
- If neither of these to options is set to true, the master has little control over the client. It only receives results from the client for hosts/services defined locally on the client. In this case, is there some command channel from the master to the client at all, like can it still trigger the execution of checks on the client (only for the predefined hosts/service)?
Is my understanding as described above correct? What are my options if I don’t want the clients to fully trust the master? I don’t think I can use any of accept_commands/accept_config, could I use some external tooling to sync the configuration between the master and clients which then applies additional sanitization? Are there other options?