Hi,
I am quite new in Icinga 2 and all, so I apologise if this question is rather inappropriate.
I was trying to setup master/satellite relation in multi-tenant way so that clients (satellite) could add host, services, etc. so that they do not have to login to out master in secured environment to do so. Also, we want it for the clients to be easy by having a director module installed on the satellite.
So far I have not been successful. I have Installed the Director module step by step on satellite server and got to the point where I need to run the Kickstart wizard.
If I tried to connect to master I get error massage " * I was unable to re-establish a connection to the Endpoint “test-icinga2-master” (10.1.91.20:5665). When reconnecting to the configured Endpoint (test-icinga2-master:5665) I get an error: CURL ERROR: Could not resolve host: test-icinga2-master Please re-check your Icinga 2 endpoint configuration (KickstartHelper.php:375)" - I am have the IP address on zone.conf and I still get this.
If I tried to connect to master I get error massage " * Unable to authenticate, please check your API credentials (RestApiClient.php:149)" and I am sure I am using the right one because there is only one API user there.
Any suggestion how to achieve the multi-tenancy with icinga2 director would really appreciated. I have been loosing my mind over it for a whole month. I was trying to find more resources to it but without success.
The director is not designed to build multi-tenant setups, thus, allowed to run at a master only. Whereas Icingaweb could be installed/connected to master as well as satellites.
For your project this might be an option: Install a master setup (incl. director) at your clients (currently satellites) and consolidate them with livestatus at your central master.
I would advise against Livestatus, since this feature isn’t actively developed anymore and a topic of deprecation discussions. Instead, rely on the backend of Icinga Web 2 (currently IDO DB, later Icinga DB) as the only true data source.
In terms of clients creating configuration, you’ll still need to have a central master which knows about this - and which can control (allow/deny) such configuration pushes. When the Director is used, you can do so with the Self-Service-API for instance. Or you’ll go with automation tools such as Puppet or Ansible, where the client facts are registered and turned into monitoring objects based on specific rules.
Putting the Director on a satellite only works for that specific zone, and from the many setups I know, this will run into problems. Our recommendation is to put the Director on the central master instance, and let deployments happen from there. If you’re not using the aforementioned Self-Service-API, you can also opt for using its REST API with creation of objects, apply rules, etc.