I would like to present the different ways to define the rights of users in Icinga Web 2. Especially in companies with many employees or with a wide circle of customers this is of high importance to answer the question whether Icinga Web 2 is productively deployable or not. Since we are heading towards our first release candidate, this post should also show what can be expected in the near future.
The Group / Role Concept
First of all, a basic introduction. Those already conversant with this subject may skip this passage. In Icinga Web 2 users (Not to be confused with Icingaâ€™s contacts. Only Icinga Web 2 is aware of its users!) have several ways to log in, e.g. via basic auth, database or Active Directory. When groups have been configured to be assigned to certain users, Icinga Web 2 registers the userÂ´s group assignments after a successful login. Now all necessary information exists to assign the available roles to a user. A role defines permissions and restrictions applicable for specific areas in Icinga Web2.
A permission defines thematically the userÂ´s rights according to the motto all or none. Regarding Icinga Web 2 itself this applies to the applicationâ€™s configuration. Through certain permissions you define what a user is allowed to configure: roles, groups or everything. The monitoring module (the actual heart communicating with Icinga) also provides the possibility of defining permissions. In this case, however, permissions apply to commands. You define whether a user has the permission to do everything or just to add comments, or to send acknowledgments and schedule downtimes. These permissions are not related to specific hosts or services but are equally valid for all.
A restriction is additionally set to a possibly necessary permission and – as its name implies – further restricts the access.
At the moment this is done by the monitoring module for hosts and services and limits the view of the actual objects, and with the release candidate also the corresponding connected data, e.g. comments, downtimes and notifications. As soon as the release candidate is available it will be extended to host and service groups and all possible aliases and custom variables. We have not taken a final decision on whether an automated connection of a user with a contact will be possible.
Regarding the custom variables there is one special feature in the monitoring module: It is possible to completely block access to certain custom variables independently from a role. This usually makes sense when sensitive data exist, like passwords etc.
The URL filtering syntax
As the definitions of a restriction for hosts and services is currently done with a URL filter (just like everywhere in Icinga Web 2) and as there is no assistance available in the corresponding configuration view yet, I will show an example of how such a filter could look like. Astute users may already have tried to use the editor in the corresponding list view because there you can currently compose the desired filters. When all desired filter are applied, its representation appears in the address bar of your browser and can be copied directly.
Here you can already see the basic structure of a filter. It can consist of connections (OR |, AND &, NOT !) and comparisons (EQUAL =, NOT EQUAL !=, GREATER >, LESS <, GREATER OR EQUAL >=, LESS OR EQUAL <=). If you want to sum conditions you have to put them in round brackets. If only hosts of the host group â€œcustomer2â€ should apply with certain custom variables, the filter has to be modified as follows: (hostgroup_name=customer1|(hostgroup_name=customer2&_host_support_level>=2))&host_name=office-*
The notation for custom variables regarding services is as follows: _service_variable_name
With this in mind, I wish you lots of fun when assigning permissions and restrictions. See you soon! Next time, I will tell you even more about the pure awesomeness of Icinga Web 2.