Zabbix user permissions explained
A simple guide to user permissions
Zabbix is an enterprise-class monitoring solution for your IT. It can monitor everything from servers (Zabbix Agent) to network devices (SNMP). If need be, you can write your own monitoring script and integrate it with Zabbix. But if you’re reading this article you already know that.
Apart from all its monitoring capabilities, Zabbix comes with a quite complex user privilege management system. In this article, I will unravel its many mysteries without, hopefully, going into too much detail.
Anatomy of Zabbix permission system
When trying to understand a complex system it is usually best to start with going through all of the bits and pieces that are a part of said system. So, without further ado, here are the important things:
Users
When granting access to Zabbix frontend, you can do so by creating a dedicated user account (please don’t share accounts). During the creation process, you will be asked to provide an alias (login), password and other stuff. Apart from that, you will need to specify at least one user group this user will belong to. This is an important decision, for reasons outlined later.
Hosts
In Zabbix a host is a monitored entity. It doesn’t really matter if you want to monitor a virtual machine, network switch or an application, more often than not it will represented as a host. When creating a host, you will be asked to provide an unique name and some other details. It is important to know that every host needs to be a member of at least one host group.
User groups
As you might expect, a user group is a container holding zero or more users. This element is important because it’s used for assigning permissions to host groups. Apart from this, you can set other access policies for a user group, such as authentication backend or whether it has access to the debug mode.
Host groups
Host groups are a collection of hosts, there is not much to be said. The only thing worth mentioning is that Zabbix actually supports nested host groups. This is done using a naming convention.
Let’s say you have a host group called ‘Datacenter’. Then you want to introduce nested groups for your facilities in Warsaw and London. To do that simply create the following groups: ‘Datacenter/Warsaw’ and ‘Datacenter/London’. What’s even better is that you can nest them to your hearts content.
User types
Up until Zabbix 5.0 there were only three types of users: Zabbix user, Zabbix Admin and Zabbix Super Admin. The most notable difference between them is that each user type has access to different sections of the frontend. Please refer to the bellow table for details.
+================+=============+==============+====================+
| | Zabbix User | Zabbix Admin | Zabbix Super Admin |
+================+=============+==============+====================+
| Monitoring | X | X | X |
+----------------+-------------+--------------+--------------------+
| Inventory | X | X | X |
+----------------+-------------+--------------+--------------------+
| Reports | X | X | X |
+----------------+-------------+--------------+--------------------+
| Configuration | - | X | X |
+----------------+-------------+--------------+--------------------+
| Administration | - | - | X |
+----------------+-------------+--------------+--------------------+
- no access
X has accessAn important take away is that Zabbix Super Admin privileges cannot be limited in any way, so be careful when giving a user this unlimited power.
User roles
Since Zabbix 5.2 there is yet another thing to consider and that thing is called user roles. The idea behind them is fairly simple: what if we took a user type and removed access to selected parts of the frontend?
Each user role is based on a user type, then during configuration you limit access to given areas of the frontend, ability to execute actions or make API calls. As you can see each new user role can have at most the same privileges that the user type it’s based on.
Permissions
Now that we know what comes into play regarding assigning permissions, let’s discuss how everything fits together.
The most important thing to remember is that you ever assign permissions on a group level. It’s a user group that has permissions assigned to a host group. This means that you need to carefully design your group landscape and actively maintain group members. This also holds true for any and all subgroups that you may have.
Access levels
When assigning permissions to a host group there are four access levels to chose from:
- Read-Write
- Read
- Deny
- None
Read-Write and Read do exactly what they advertise. The first one allows for viewing and modification of host group members, the other one allows for viewing only. In case you’re wondering: without Read access you cannot see related problems, latest data or inventories.
Deny will, well, deny access to a host group. It is especially useful when dealing with nested host groups — you might want do give access to a group with all its subgroups except for one. Then you would set the desired access level to that host group (including subgroups) but set Deny for that specific one. It also plays a significant role when user is a member of multiple groups.
Setting access to None removes the host group from the list. You can treat this as ‘reset to defaults’.
After all desired user groups are mapped to host groups you could take a peek into a user’s profile and check his (calculated) permissions for different host groups. Note that this view is read-only. There are also some things to consider when managing several user and host groups, but you might want to refer to the docs for those.
Access levels and user types (user roles)
Zabbix has three user types and access level for a host group affects them differently. Bellow you’ll find a nice table representing what happens when giving different users different access levels and the effective value.
+============+=============+==============+=====================+
| | Zabbix User | Zabbix Admin | Zabbix Super Admin |
+============+=============+==============+=====================+
| Read-Write | Read | Full | Full |
+------------+-------------+--------------+---------------------+
| Read | Read | Read | Full |
+------------+-------------+--------------+---------------------+
| Deny | None | None | Full |
+------------+-------------+--------------+---------------------+
Read - Read-only permissions
Full - Read-write permissions
None - well, no permissionsWhat is this wizardry you ask? Well, it is the consequence of what a user can do in frontend (first table). Zabbix user may have Read-Write access level granted, but since the Configuration tab is inaccessible to him, not much can be done in terms of Writing. On the other hand Zabbix Super Admin can be denied access to every single host group, but will still have full control over them. It gets even more complicated with user roles as you get to pick and choose what frontend sections are accessible to who.
Notifications
There is something important to be said about Zabbix actions in the context of user privileges. To receive notifications about some problems on a host, you must have at least Read permissions to it. When you use a Zabbix Super Admin account on a daily basis it is easy to get accustomed to having access to everything and even easier to forget adding yourself to relevant host groups. And without that you might miss out on some important notifications.
Tag filters
It is also possible to limit what problems a user can see in Zabbix. This can be done via tag filters in user group configuration. You may specify a list of tags (their names and values) a group should be able to view. Then Zabbix will filter out any problem that wasn’t tagged with at least one of them.
Conclusion
In this article we had a look at the anatomy of Zabbix permission system and how some components work with other. Hope you found this helpful, if you have any questions, ask away.