Learn Zabbix - Authentication, RBAC & Security Hardening

#Introduction

A Zabbix that collects data across the entire infrastructure is both an asset and a target. Episode 15 shifts the focus from functionality to security: who can log in, what they're allowed to do, and how to protect the data path from agent to frontend.

Three layers map this episode. The first layer, authentication, determines identity. The second, RBAC, limits authority. The third, hardening, secures communication, the database, and internet exposure. All three are prerequisites before Zabbix can be considered production-ready.

#Authentication

#Built-in Users and Passwords

Zabbix ships with a built-in Admin user. If episode 3 didn't do it, change the zabbix password right away. For production, disable unused built-in users and set up a per-person account with limited permissions.

#LDAP/AD and SAML SSO

For organizations already using a directory service, Zabbix supports external authentication:

• LDAP/Active Directory: users use corporate credentials, and AD groups can be mapped to Zabbix user groups.
• SAML SSO: centralized login through an identity provider such as Okta or Keycloak.

LDAP host:  ldap.example.com
Base DN:    ou=people,dc=example,dc=com
Bind user:  cn=zabbix,dc=example,dc=com

With SSO, account administration moves to the organization's identity team — passwords are no longer managed inside Zabbix.

#2FA

Zabbix supports two-factor authentication (2FA) with TOTP-based authenticator apps. 2FA is enabled per user or mandated for specific user groups. For admins with full configuration access, 2FA is a non-negotiable defense layer.

#RBAC: Role-Based Access Control

#User Groups and Roles

A role defines the type of access: Super admin for everything, User with admin role for limited administration, User for operations, and Guest for restricted read access. Roles can be customized down to the per-section permission level.

Users are grouped into user groups, and roles are attached to user groups. This structure allows different teams to be treated differently within one deployment.

#Permissions on Hosts and Host Groups

Permissions determine which host groups a user group can see and modify. A common pattern:

On-Call Team: read + write   on Linux/Production
Dev Team:     read only      on Linux/Development
Management:   read only      on all host groups

Tidy permissions let operational teams work without risking damage to configuration outside their responsibility. In Zabbix 7.0, permissions can be set down to the level of UI elements, scripts, and modules.

#Network and Database Hardening

#TLS/PSK Between Agent and Server

Traffic between the agent and server isn't required to be encrypted, but it should be secured in environments crossing untrusted networks. Zabbix supports TLS/PSK (pre-shared key) and TLS with certificates. With PSK, both sides share a secret key:

openssl rand -hex 32

The output of openssl rand -hex 32 is a hex key placed in TLSPSKFile on both sides. The configuration in zabbix_agent2.conf:

TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=host-target-01
TLSPSKFile=/etc/zabbix/zabbix_agent2.psk

With TLSConnect=psk and TLSAccept=psk, the agent only accepts PSK connections. The server uses the same TLS parameters on its side to connect to it.

#Database Encryption

The database stores all configuration and metrics — including potentially sensitive data. Make sure the server-to-database connection runs over an encrypted connection, and consider encryption-at-rest per organizational policy. Database credentials in zabbix_server.conf must be protected with strict file permissions.

#Nginx Reverse Proxy with HTTPS

Never expose the Zabbix frontend directly to the internet without HTTPS. Put the frontend behind a reverse proxy (Nginx or Caddy) that handles TLS certificates:

server {
    listen 443 ssl;
    server_name zabbix.example.com;
    ssl_certificate     /etc/letsencrypt/live/zabbix/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/zabbix/privkey.pem;
 
    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

The block proxy_pass http://127.0.0.1:80 forwards HTTPS traffic to the local frontend. With this pattern, certificates, restrictions, and logging are centralized at the reverse proxy.

#Patches and Security Advisories

Zabbix publishes Security Advisories for discovered vulnerabilities. Follow the release policy: upgrade to the latest patch release for the branch you use, and monitor official sources at zabbix.com for security announcements. For isolated networks, test and apply upgrades on a schedule.

#A Short Security Checklist

• Change and disable all unused built-in users.
• Enable SSO or LDAP, and 2FA for admin accounts.
• Apply roles and permissions per host group.
• Secure agent-server communication with TLS/PSK.
• Put the frontend behind an HTTPS reverse proxy.
• Protect database credentials and monitor Security Advisories.

#Closing

Episode 15 closed the networking and security phase: authentication with built-in users, LDAP, SAML SSO, and 2FA, RBAC with user groups and roles, and hardening with TLS/PSK, database encryption, an HTTPS reverse proxy, and security patches.

Key takeaways:

• Change default passwords and disable unused users.
• SSO and 2FA move identity management and add a defense layer.
• Roles and per-host-group permissions limit the impact of every user.
• TLS/PSK secures agent-server communication.
• The frontend always sits behind an HTTPS reverse proxy in production.

In the next episode 16 we'll discuss high availability and disaster recovery — building a Zabbix server HA cluster with active and standby nodes, configuring HAClusterNodes, and backing up and restoring the database and configuration for disaster recovery.