Hello everyone. I am using Icinga2. It is a great tool. But I have question. If i create a host template and put it to global zone like:
template Host “host” {
check_command = “ips”
max_check_attempts = “5”
check_interval = 5m
retry_interval = 1m
enable_notifications = true
enable_passive_checks = true
enable_flapping = true
enable_perfdata = true
vars.pass = “1234”
}
This template is synced to satellite and agent, so other users who access satellite and agent can see vars.pass and other information. They can get information about apply services and service set too. Could you tell me that Is there any best practice about this? Many thanks
1 Like
I’m not convinced it’s a real problem.
On my Satellites, the directory /var/lib/icinga2/api/zones/global-templates is
owned by nagios (might be icinga in your case, depends on the distribution)
with permissions 700, so only a user with access to the nagios/icinga account
can see the information contained.
The nagios user in /etc/passwd has a login shell of /bin/false, and the passwd
in /etc/shadow is disabled.
No other user is a member of the nagios group.
So, what all this comes down to is that the only possible user on the system
who can read what’s in those files is root, and if you don’t trust whomever has
root access on the Satellites and Agents then I don’t think you’re going to
find a solution to the problem you think you have.
Regards,
Antony.
1 Like
Thank you for explaining. However, some agents are on customer sites. It is not controlled by me. 
Hello,
I agree it can be quite an issue if you have user/pass or variables with sensitives data in your global templates zone directories, it may not be directly an issue for linux system users when read rights are properly sets, but i’m not sure it’s the case for windows agents.
Right now, all icinga config files are not meant to store secrets, if you want to do so, that’s a potential risk.
To minimize it you could directly store a hash of the password in the vars.
@theFeu
Regarding this situation, it may be an idea to have the possibility to either apply globals zones for nodes matching a pattern (like common apply rules) or store replicated config files issued from parents zones in a ciphered form on child node.
If you store a hash of the password in the host vars, how do you then use the
password to authenticate?
Antony.
@Pooh
you directly compare hashes of the 2 passwords (i’m assuming here you use a hash algo with low collision probabilities), pretty much the same way to work with database, you dont store passwords in clear text in it.