Last week we released the final first version of Icinga DB and its web interface module Icinga DB Web. Icinga DB Web offers many new features and a completely new design.
The monitoring module has its limitations when managing a role, as it handles permissions and restrictions separately. This means that the permissions for a role are not related to the restrictions of the role To understand this better, here is an example:
Suppose we have a user MrSmith who has the following three roles:
- Read access role for both monitoring and Icinga DB Web: The user has permission to only see all hosts and services but is not permitted to add comments, acknowledgment, etc.
- Admin access role for the monitoring module (everything allowed but with one restriction): The user can do everything, but he is restricted to only hosts.
- Admin access role for the Icinga DB Web (everything allowed but with one restriction): The user can do everything, but he is restricted to only hosts.
In the monitoring module, due to the Read access role, the user can see all hosts and services and due to the Admin Access role, the user should have admin access, but only for the hosts. But he has admin access to the services as well. But why?
On the one hand, the Admin access role allows him administrative access to all hosts, on the other hand, with the other Read access role, he can also see all services and has administrative access to them as well.
Icinga DB Web solves this limitation by combining permissions and restrictions for a role to manage them. This means that permissions and restrictions are tied to each other based on the role. If the user has permissions and restrictions for a role, all of his permissions are allowed only for his restricted area for that role.
