icingaweb2-module-director
icingaweb2-module-director copied to clipboard
Icinga
Respect Service Template Zones in Service Sets
Expected Behavior
I want to be able to put Services in specific Zones by tweaking their Templates
Current Behavior
While this works fine for Single Services (and Apply Rules), it doesn't work as expected for Service Sets. It's possible to tweak the zone property of the Service, but Service (Set) Apply Rules are still rendered to the global zone.
Technical reason: the "main" object tells the Config Renderer about it's preferred Zone. In this case, the Set is this "main object". As the Set has no Zone, the Renderer falls back to it's default decision tree. It never "talks" to single Services, as they do not exist at all - the Set generates them on the fly for rendering purposes only.
Possible Solution
Fix this :rofl:. And have a look at #1589, it is related.
There is also a security aspect to this: Currently, if one sets a password as a variable (custom properties) on a service in a service set, the password is deployed to all the agents and can be found as plaintext in /var/lib/icinga2/api/zones/director-global/director/servicesets.conf. This can leak the password to unauthorised parties, especially in multi-tenant organisations with a centralised monitoring system. This forces one to set all the passwords on the host directly, which can be unwieldy.
For example, if we have a service set for our mysql-servers including the password for the database connection, this password can be found on all the other hosts as well, even if they are not using said service set. This means the external development company that has root-permissions on a dev-system can get the mysql password.
This could be prevented by setting the zone to master, if this option is implemented.
I also discussed the security aspect in the Icinga community. https://community.icinga.com/t/how-to-store-passwords-credentials/8029 Setting zones to services or service sets would be definitely the best solution.
@bobapple: sure! It's already in the master, but was pinned to the wrong GitHub milestone. Has been fixed, thank you!