Permissions over Distributed Monitoring

Hey there.

I’m evaluating check_mk for the following scenario:

site A:
hostA1, Server
hostA2, Switch
hostA3, Hypervisor
hostA4, Application

site B:
hostB1, Server
hostB2, Switch
hostB3, Hypervisor
hostB4, Application

site C:
hostC1, Server
hostC2, Switch
hostC3, Hypervisor
hostC4, Application

all information are fetched from the central site via livestatus:

central site:
hostA1, Server
hostA2, Switch
hostA3, Hypervisor
hostA4, Application
hostB1, Server
hostB2, Switch
hostB3, Hypervisor
hostB4, Application
hostC1, Server
hostC2, Switch
hostC3, Hypervisor
hostC4, Application

Now, the challenge:

Group userSVR should see hostA1, hostB1, hostC1
Group userSwitch should see hostA2, hostB2, hostC2
Group userHV should see hostA3, hostB3, hostC3
Group userApp should see hostA4, hostB4, hostC4

I can give guidelines for the local sites (e.g. certain folders or groups). What are the major steps to achieve this?

(Please, do not look for the purpose of this, it is a business requirement for compliance)

I would suggest to create 4 contact groups. Then put the hosts into these 4 contact groups and also assign these contact groups to the users.

I.e. put hostA1, hostB1, hostC1 into contact group “Svr” and assign all users in group userSvr that contact group. By default every user can see only “things” (hosts and/or services) for which he/she is a contact. (Except admins, they can always see everything, no matter their c.g.)

See also the docs:

Thanks for your answer.

Do I have to create these contact groups at the remote sites, the central site or both?

If both, I assume they have to match exactly?

If you use distributed monitoring and replicate the configuration from the central site to all the remote sites, then you would create the contact groups and memberships only on the central site. In fact, you would literally configure everything on the central site and nothing on the remote sites.

Honestly, I have no idea what to do if you do NOT replicate the configuration. I don’t know which configuration then wins.

Beware: Do not change the replication setting to “Push…” without knowing what you do, because then the complete configuration of the remote sites gets overwritten with the central site’s configuration.

1 Like

The central config approach is not possible in my environment. But this gives me the hint that the contact groups should be on both end.

My theory: both have to match (and the contact groups are transmitted via livestatus). So if I put a host on local site into cg_server and if I create cg_server on central site and give a user group the right to see it, it should do the trick.

Let me test that…

I created:

central site:

  • user cmkadmin, user netmen (cg_Network)
  • cg_Network and cg_Server created
  • Testserver (cg_Server via folder and rules), Testswitch (cg_Network via folder and rules)

rem1 site

  • cg_Network and cg_Server created
  • Server1 (cg_Server via folder and rules), Switch1 (cg_Network via folder and rules)

rem2 site

  • cg_Network and cg_Server created
  • Server2 (cg_Server via folder and rules), Switch2 (cg_Network via folder and rules)

Central site as cmkadmin:

Central site as netmen (it lacks Switch1 and Switch2 from rem1 and rem2):

1 Like

Hmm. As said, I’m not sure what to do when the config replication is turned off. Did you also create the user netmen on the remote sites and put him in the cg_Network there?

1 Like

Oh well, no! Indeed, it works, now. After creating the netmen account at rem1 and rem2 with cg_Network and the same password, it works:

Perfect, thank you very much @Dirk

1 Like

Glad to hear but it was just guesswork on my side.
However, when I think about it, it makes sense because if you’d enable the config replication, then the central and all remote sites would also have the exact same CGs and users.

By the way,

the contact group is relevant for the system itself. I revoked the contact group for netmen at the central site. As result, I see no hosts at central site, but still from the remote one’s:

To sumarize: the username has to fit for central and remote sites. The visibility of the hosts is determined by the contact groups of the respective local user account and its contact groups.

1 Like