Add (optional) allowed endpoints to global zones configuration

[Mikesch-mp]

Is your feature request related to a problem? Please describe.

If you create a global zone which should only exist on masters and satellites (on many different zones), which hold sensitive data like passwords etc. , and dont add this global zones on agents. The agent will log

warning/ApiListener: Ignoring config update from endpoint 'some.host.fqdn' for unknown zone 'internal'.

With this information an user can easily add the zone on an agent and get the zone also synced to the agent and get the sensitive information out of this global zone.

Describe the solution you'd like

There should be an option with an filter/array which endpoints are allowed to sync this global zone.

object Zone "mysecretzone"  { 
    global = true 
    endpoints = [ "master02", satXY01", satZZ02" ]
}

## Describe alternatives you've considered

There is no alternative, because if you have access to the logfiles and a litle bit knowledge on how icinga2 works, you can just add the global zone and see its content after a reload.

[Al2Klimov]

Shouldn't passwords be stored in services' custom variables?

[Mikesch-mp]

Yes they should, but not everything should be synced to agents. Global zones will be synced and if you know the name you can easily configure it on the agents and see its content.
For some services, api users etc. configuration which should not be synced and it is not needed to sync them to th agents it should be possible to disallow the sync even if (a evil admin/owner of an agent) reconfigure the agent to sync it.

Just think about enterprise installation with a lot of different owners/customers/compliance rules.

[Al2Klimov]

IMAO one should not put the respective services in global zones then.

[stevie-sy]

I would like to join in on this topic and I agree @Mikesch-mp with this feature-request. It's not only passwords! Think about the director with his "director-global" zone. Everything which is configured there with it you'll find in this zone (incl. passwords). Until there is no solution to limit this, such idea would be great.
What I mean it's not necessary to sync the snmp password from a network device to a database server, because it's in the director-zone!
I wrote some examples in this old bugs/feature-request:

• /var/log/icinga2/icinga2.log is growing very fast on satellites  #6542
• Change Cluster Zones In ServiceSet icingaweb2-module-director#1589

[Mikesch-mp]

@Al2Klimov not everything is for non global zones. To make it easier for you to understand think of this.
For Agents that dont have access to the master nad only access to their satellites, you need an api user for the sattelites to enable create tickets for the agents, as for now i can put it in global zone, which is a bad idea or in the zone for the satellites (good idea because it doesnt get synced to agents). But i have to create the same api user for all zone, which is anoying if you have a few hundred zones. Better put the api users into a global zone which will be only synced to satellites, so you have only to define your api user once. Problem here is that the agent see this "unknown" zone in their log file and can get it synced by adding it to the agents zone.conf -> User/Customer/Spy can see passwords or other things they should not be able to see.

Hope this makes it a bit clearer for you.

Regards,
Carsten

[araujorm]

This feature would solve another problem I'm having.

I have zones for several customers which I manage from my master host with director.

One particular case of a customer has, besides its own satellite, many sites for which I've created sub-zones (let's call them like that), with each satellite of those sub-zones connecting to the customer's satellite (let's call them 2nd level satellites).

It works as expected except for one request the customer made recently: they want some default thresholds for all their windows machines (on their zone and sub-zones) to be different. So I created a host template which inherits from my global windows template, put it in the customer's zone and thought it would be a no brainer... but since the template is on that zone only, it isn't usable in the sub-zones, more specifically when I try to add it to client hosts on those sub-zones (which are behind the 2nd level satellites).

Then I realised that template would have to be on a global zone, and created one named mycustomer-global-templates, with parent mycustomer-zone, and added that zone as global on each of the 2nd level satellites' zones.conf. It works, but now all other machines not under the mycustomer-zone, and with the exception of the master itself, get errors on their logs about receiving config updates for a unknown zone named mycustomer-global-templates, which not only reveals that customer's name to each of the other zones and unrelated customers, pollutes the logs, and as I understand from the above comments would allow any of the machines to "subscribe" that global zone even if I declared it as having mycustomer-zone as the parent.

With the proposed filters, I could work around this, as I understand. Are there any plans to implement them? (first in icinga2, then in director module, but for director I could propose a patch, as long as it was implemented in icinga2 in the first place)

[RincewindsHat]

Ping!