Alright, I guess that's a valid point - I definitely wasn't thinking about scenarios in which you trust the monitoring server but don't trust it's admins and the checks they configure (it seems a bit extreme but I can see the idea).
An alternative solution to this problem: you could have a satellite icinga server managing your machines via remote command execution. Your command execution bridge machines trust the satellite only (at the SSL level), which is where you configure the checks: the satellite and the end machines are at the same level of trust. Then you can have a master which aggregates all the checks, but which doesn't define the checks. This way you define clusters of trusts enforced by SSL and have fine-grained control over who can run checks on each machine. But if NRPE-based command restrictions works better... On Tue, Jun 30, 2015 at 1:14 AM, Dustin Funk <[email protected]> wrote: > Am 29.06.2015 um 07:01 schrieb Shay Rojansky: > > From what I understand arguments in icinga2 don't represent a security > risk > > simply because the connection itself is secured via SSL > > The question isn't whether the informoation channel is secure. It's more > a question whether the monitoring-client trusts the monitoring server > when the client allows arguments. > > > > NRPE represents a much lower level of security, > > Nobody said that NRPE is secure. > > > which is why you need to worry about > > arguments and security > > .. thats _only_ one point. Another is when server and client are > administrated by different people or instances. > > nuts > > > _______________________________________________ > icinga-users mailing list > [email protected] > https://lists.icinga.org/mailman/listinfo/icinga-users > >
_______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
