This post is also available in: French
When a monitoring software is implemented, it serves many users whose needs often differ.
The ACL or Access Control Lists can define “who see what?” and “ “who act on what?”. Sometimes, they may be difficult to manage. Here is a useful methodology to understand and manipulate them.
In Centreon, you should start by defining the ACLs. It’s an important step because you have to define “user profile” and ask yourself “what is this type of user looking for?”
First of all, you must know that a user with administrator rights is not subject to any ACL. This means that he has access to everything and can perform all possible actions. This is the equivalent of “root” on a Linux server.
A non-admin user has by default access to nothing. It is necessary to place him in an access group and set his access rights.
It is important to think in terms of “user profile” and try to group all the users according to their needs.
In Centreon, we call them “Access groups”.
- Windows administrators: put together all Windows administrators
- Linux administrators: put together all Windows administrators
- XXX administrators: put together all XXX administrators
- Pilots: put together all users of steering team
- Head of Application X: put all together all managers of X application
In the same way as contact groups, the configuration of access group has to be based on the internal organisation of team and IS.
To configure access group, please go to the menu « Administration → ACL → Access groups » and click on the link « Add »:
In the data form, you can write in the “General information” tab:
- access group name
- a description ;
- contacts group related to content in this access group
All the other tabs help you to configure all resources associated to this access group
You can find some details about the other menus below.
The menus accesses allow you to define “who have access to which functionalities?”
For example, an access group can have some rights on monitoring menu but not on configuration menu. Another group can have access to reporting menu but not monitoring menu.
For menus access, don’t focus on unit access group. So don’t take the first access group asking yourself “what access does this group need?”
It is best to position the types of profiles using the interface. You avoid multiplying configurations.
For example, you define the same menus access for access group “Windows administrators” and “Linux administrators”. You can simplify the access configuration by using the existing Centreon user profiles. This is some examples:
- « monitoring »: you have access to monitoring interface and different submenus
- « reporting »: you have access to reporting interface
- « metrology »: access to monitoring graphs. Sometimes, this access can be merged to « monitoring »
- « default »: access to menus by default (« home » page, « about » page ,« password change» page )
Once the user profiles are defined, you have to choose what linked access group have access to these use profiles.
For example, user profile «Windows administrators” access to use profile “monitoring” or “metrology”. The user profile “Application XXX manager” access to use profile “monitoring” and “reporting”.
The more precise the configuration is, the easiest it will be to maintain. So, be very careful when creating it!
The user profiles defined above operate in 80 % of cases, but they deserve to be systematically refined to match the organisation of the team and IS.
To configure user profiles, please go to the menu « Administration → ACL → Menus Access»
2 steps to realise this configuration:
- choice page access group
- allowed page choice: to click on the checkbox, the user profile have access to the page and all subpages and to click on the + and you access to the list of subpages.
It is in this section that tells you what resource the users profile access.
There are 2 subtleties to know: exclusions and filters.
You configure in the menu « Administration → ACL → Resources Access ».
First, it’s necessary to define the name of resources access and the impacted users’ profiles
Then, you define which resources you can associate. You can also configure selecting hosts, host groups and excluded host.
If you check the box “Include all hosts”, the users profiles can see all hosts. If you check “Include All hostgroups”, the impacted users profiles can see all host groups.
About the host exclusion: it is only for hosts included in host group. It means that we can give access to user profile for a host group except some hosts.
For example, I can give access to all hosts from host group except the hosts “bart” and “marge”.
In the tab “Resources services, you can give access to services groups.
ACLs allow you to give access to meta-services.
The last tab help you to add filter on objects already added. In other words, you can give access to all host groups filtering an element. So, only the objects associated to this filter can be visible by the user. The filters are:
- Poller: only the hosts associated to this poller are visible by the user.
- Host category: only the hosts associated to this category are visible by the user.
- Service category: only the services associated to this category are visible by the user. All other services are invisible.
The filters are complexes and to understand them better, this is some case-studies:
- The Head of ERP application will be associated to host group which contain all ERP application hosts. He will be associated to filter of category service “ERP”: only monitoring services of ERP (process, errors in the log, connection time of users, exchange/data transaction) will be visible. All other services (CPU, memory, database…) will be invisible.
- The administrator of Windows servers of the customer X will be associated to host group “Windows”: he can see all windows servers. But, he will be associated to category of host “Client X” and can see only Windows servers of this client.
- The previous example also works when a client is associated to only one poller: you can filter on the poller’s name.
The action access allow you to define what monitoring actions a user profile can realise on the objects to which he has access. A user can take an alert or not, restart a test or not…
Some of these actions can be done by anyone:
- take an alert
- add a downtime
- restart a test
Other actions must be given only to monitoring administrators or someone who manage this. Some actions can be “dangerous” if they are poorly made. Some examples:
- To stop notifications: if you stop notifications for equipment, no alert will be sent (push) and the user will have to look for the information (pull).
- To stop the monitoring: host or service monitoring can be stopped in unit time for undefined time. It is recommended that you never inactive the monitoring but just you install a downtime with a define time.
- To stop passive collect: you should know what the passive collect is before to stop it.
As menu access, you have to define user profile
Examples of frequent profiles established:
- Read only mode: the users can’t realize any monitoring actions
- Standard monitoring actions: to add a comment, to delete a comment, to restart a test
- Broad monitoring actions: writing operations, deletion of writing operations, adding a downtime, deletion of downtime
These rights are defined in the menu « Administration → ACL → Actions Access ».
As all the configuration of the monitoring platform, the ACL have to be set to reflect the organisation of your Information system. Complex to define, they deserve some attention, especially for menus and actions access.
So remember to define precisely the users behaviors, Centreon user profile rather than start from the user groups.