One of the focuses of version 2.9 of Icinga Web 2 will be on access control. For years on now, Icinga Web 2 had a very simple role based access control (RBAC) implementation:
- Users can occupy multiple roles
- Each role provides a set of permissions
- Each role provides a set of restrictions
- Multiple roles are merged additively
This suited most of our users fine. However, there were still some requests to enhance this further:
- Role inheritance
- Permission refusals (aka deny permissions)
- Linkage of permissions and restrictions
The next major update of Icinga Web 2 (Version 2.9) and Icinga DB Web will allow users to configure exactly this.
Disclaimer: The following will mention the term monitoring multiple times, by which the monitoring module is NOT meant though!
Role Inheritance
Two roles, where one role inherits privileges from another one, will still be merged additively. The difference is that a user doesn’t need to be a member of both roles. Let me give you an example on that:
Example
Given the roles monitoring-user and monitoring-support, monitoring-support inherits from monitoring-user. So monitoring-user is the base role for monitoring-support.
monitoring-support <- monitoring-user
Given the users john-doe and jane-doe, which are a member of role monitoring-support and monitoring-user respectively.
| User | Role |
|---|---|
| jane-doe | monitoring-support |
| john-doe | monitoring-user |
john-doe is granted access to the entire monitoring, though read-only. Since monitoring-support inherits from monitoring-user, jane-doe is granted the same access to the monitoring, though with the ability to acknowledge problems.
The advantage of the inheritance is that any change made to monitoring-user will also affect jane-doe. Say that we only want monitoring users see a very specific subset of the monitoring (e.g. specific host- or service-groups) we would add a restriction to role monitoring-user. Now also jane-doe sees only this part of the monitoring. Once we also grant role monitoring-user the permission to add comments, not only john-doe can comment on hosts and services, but also jane-doe.
Permission Refusals
Permissions usually grant access. Refusals will revoke said access. Simple, isn’t it? Fine, I’ll give you another example:
Example
Given the previous example, we add another role monitoring-customer. This role also inherits from monitoring-user. But we don’t want our customers to complain about our support reaction time in host or service comments.
So we refuse monitoring-customer the permission to add comments. Or any of the command permissions, to avoid granting such a permission mistakenly if we’re changing role monitoring-user again.
This will also refuse these permissions if they’re granted by any other role outside the inheritance path. That’s why refusals should be utilized rarely and only with appropriate attention.
Linkage of Permissions and Restrictions
In Icinga DB Web, granted permissions only apply to objects that are available due to the very same role that provides the grants. I’m sure an example for that is welcome:
Example
Given the previous examples again, we add one more role internal-monitoring-support that provides access to the monitoring with all command permissions granted but restricted to hosts and services part of our internal network.
We define that jane-doe is also a member of this role.
| User | Role |
|---|---|
| jane-doe | monitoring-support, internal-monitoring-support |
| john-doe | monitoring-user |
In the current version of the monitoring module, jane-doe has now also all command permissions (including downtime schedules) granted on hosts and services which are available due to role monitoring-user. (from which monitoring-support inherits) That means, jane-doe can schedule downtimes there.
Icinga DB Web however, will strictly differentiate which role is responsible that a particular host or service is available to jane-doe. If it’s a host that’s part of our internal network, it will only ask role internal-monitoring-support for e.g. the permission to acknowledge problems. If the host is not part of the internal network and instead available due to role monitoring-user, scheduling a downtime won’t be possible.
Audit View
And here’s a goodie for all who have read this far:
Icinga Web 2.9 will feature a full fledged audit view! Since we add more complexity to our access control implementation, I’m sure many of you will be glad to have a view with which you can inspect the effective privileges of a particular user or group easily!
