User Restrictions and Roles in Icinga Web 2

restrictions
rbac
icinga2
icingaweb2

(Michael Friedrich) #1

Introduction

This howto shows you how to restrict/limit user access onto monitoring objects in Icinga Web 2.

This depends on common configuration best practices in Icinga 2 with groups and custom attributes.

This is a community howto enhanced by many. If you have additions, edit the topic or start a discussion below.

Author: @dnsmichi

Revision: 0.1

Tested with:

  • Icinga Web 2 v2.5.x
  • Icinga 2 v2.8.x

Requirements

  • Icinga 2 is configured and running
  • Icinga Web 2 using the default admin account is running and presents all monitoring data
  • Basics from the documentation (Icinga 2, Icinga Web 2)

Configuration

Patterns and Groups in Icinga 2

Start simple with just one HostGroup, e.g. by using the one found in conf.d.

https://www.icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/#groups

Example, please adjust for your own needs.

object HostGroup "linux-servers" {
  assign where host.vars.os == "Linux"
}
object HostGroup "windows-servers" {
  assign where host.vars.os == "Windows"
}

Check that the Icinga Web 2 Hostgroups overview lists it and it has some hosts inside it. Ensure that there are other hosts which are not part of this group.

Create an Icinga Web 2 User

Now create a new Icinga Web 2 user underneath Configuration > Authentication > Users.

https://www.icinga.com/docs/icingaweb2/latest/doc/06-Security/

Groups

You can optionally create a new user group and add users as members. This can be later used for easier role management.

Imported AD Users

If you are managing your users externally, e.g. imported from LDAP, choose the corresponding groups as best practice.

Permissions and Restrictions

In terms of permissions and restrictions, read on in the monitoring module’s docs to gain more insights: https://www.icinga.com/docs/icingaweb2/latest/modules/monitoring/doc/06-Security/

Roles

Next, create a new role for the linux-team for example. Assign them read only access for the monitoring module, allow to ack, comment, add downtimes but not delete them.

The main restriction must be defined for monitoring/filter/objects. In this example, the user should only see the hosts and services inside the linux-servers group.

hostgroup_name=linux-servers

Create the role.

Test Restricted User

Now open a different browser or an incognito tab, and log into Icinga Web 2 with the restricted user. Navigate on the dashboard and pick the hostgroups. You can only see the hosts assigned to this specific host group :slight_smile:

Navigate into the host and service detail. You can see that the user is not allowed to reschedule a check (as this could hammer the remote client, or influence SLA reporting).

12

Different example: Schedule a downtime with the restricted user and try to delete it. The X icon is not available.

28

Conclusion

Specific restrictions and limited views are mandatory in modern monitoring environments. Commonly used best practices use name patterns, host groups and custom attributes for filtering objects for specific user groups.

Such restrictions and roles are also required by public dashboards where the user only needs read-only access to view the monitored objects and their state.

Application specific things, logs, etc. or for example configuration management with the Director should only be possible for the actual admins, and not publicly available to anyone.

The more complex your filters are, the more work needs to be done by the database backend. Keep that in mind when building these restrictions into your large scale environment.

FAQ

More Restrictions

Generally speaking you can use all the list view filters you’ve created in the filter editor. Common best practice is to use custom attributes too, e.g. where vars.os is set on the Host object in Icinga 2.

Modules

Icinga Web 2 modules can provide their own restrictions. Once installed and enabled, these permissions are available in the roles configuration form.

Automation

Icinga Web 2 stores the configuration in /etc/icingaweb2 by default. Generate it just once from the web configuration wizards and automate your deployment based on these example (or the ones provided in the documentation).


Separating monitored hosts by account type
Config menu and others missing
(Ahmed Benmoussa) #2

Hello @dnsmichi

Please allow me to add that, you have to be sure that there is no space between the parameter and the value otherwise the filter won’t work, like in the exemple below:

hostgroup_name = linux-servers

I experienced that :smile:


(Michael Friedrich) #3

Note: I am using Icinga Web 2 v2.5.x.

This works for me.

[linux-team]
users = "michi"
permissions = "module/monitoring, monitoring/command/acknowledge-problem, monitoring/command/comment/add, monitoring/command/downtime/schedule"
monitoring/filter/objects = "hostgroup_name = linux-servers"

(Ahmed Benmoussa) #4

I am using:

  • icinga2 v2.4.1
  • icingaweb2 v2.1.0

I assume that I should update them :slight_smile:


(Michael Friedrich) #5

I’ve edited the wiki entry and added the tested versions. This also is now added into the guidelines :slight_smile:


(Laszlo Laszlo) #6

Hello Guys,
I’m very new in Icinga2 and its components but I like it very much. I use Icinga2 (2.5.1.), Icingaweb2, Director, Grafana (1.1.10).
Is there any way to clone a Role? I definied a Role which will be good for my customers. I just want to edit hostgroup_name filter in every Role. So I like to clone the “master” Role and customize only hostgroup_name filter.
Thank you.

best regards,
Laci


(Peter B) #7

@KisDupla best way is to edit /etc/icingaweb2/roles.ini manually and copy/edit lines as you see fit.


#8

What about adding permission to view custom objects? Specifically performance data from PNP4Nagios. I created a very specific group for my purchasing team to watch the consumables in our printers. Everything works like a treat, I just can’t see the perfdata graphs…


(Michael Friedrich) #9

That’s way off topic for this howto discussion. Please create a new topic.