Repository navigation
Add Zabbix agent rules - #15128
Add Zabbix agent rules#15128israel-villar wants to merge 4 commits into
Conversation
Zabbix is a widely used open-source network monitoring solution; the project already has SELinux booleans referencing it (sebool_httpd_can_connect_zabbix, sebool_zabbix_can_network) but no rules covering the monitoring agent itself. Adds a new zabbix service group with three rules: - package_zabbix_agent_installed and service_zabbix_agent_enabled (from templates). - zabbix_agent_server_configured: check-only, verifies Server and ServerActive are set in zabbix_agentd.conf and not left at the packaged 127.0.0.1 default. No remediation is shipped, since the correct monitoring server address is site-specific. Adds the zabbix component. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
zabbix_agent_server_configured has custom OVAL (not template-based), so it isn't covered by any template's built-in test suite. Adds 5 scenarios covering the AND of the four OVAL criteria: both directives configured (pass), both left at the packaged default, either directive missing entirely, and either directive individually left at default while the other is configured (fail). Verified with Automatus against the debian13 test container: all 5 scenarios evaluate as expected. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Hi @israel-villar. Thanks for your PR. I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Hello @israel-villar, thanks for the submission. In order to consider this for a review, and to review this properly, please provide exact official Zabbix documentation sources for the decisions you made when creating these rules. Also please provide full documentation (comments) into the test benches you provided (expected results) Thanks. |
| @@ -0,0 +1,7 @@ | |||
| name: zabbix | |||
There was a problem hiding this comment.
Thanks for the review, @macko1. Here are the exact official Zabbix sources for the decisions in this PR:
Server / ServerActive directive names and semantics — Zabbix agent (UNIX) configuration parameter reference:
https://www.zabbix.com/documentation/current/en/manual/appendix/config/zabbix_agentd
This confirms Server governs passive checks (mandatory unless StartAgents=0) and ServerActive governs active checks, which is why the check requires both to be set.
The 127.0.0.1 "packaged default" — the official upstream Zabbix source repository ships zabbix_agentd.conf with these two directives uncommented and set to 127.0.0.1:
https://github.com/zabbix/zabbix/blob/master/conf/zabbix_agentd.conf#L132-L200
(see ### Option: Server and ### Option: ServerActive — the parameter reference page itself documents no default, but this reference template is the file that ships as-is in the zabbix-agent package, which is why an unmodified install ends up with both directives pointing at 127.0.0.1.)
Passive vs. active checks concept, explaining why both directives are relevant to a correctly-configured agent:
https://www.zabbix.com/documentation/current/en/manual/concepts/agent
I've also pushed a commit adding expected-result comments to each test scenario per your second request (587f3a8).
Add a comment to each Automatus test scenario explaining what it exercises and the expected pass/fail outcome, as requested in review. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
macko1
left a comment
There was a problem hiding this comment.
Also please provide a simple way how to review it on a product:
i.e. install zabbix agent or RHEL9 and run test X.
Thanks.
| template: | ||
| name: package_installed | ||
| vars: | ||
| pkgname: zabbix-agent |
There was a problem hiding this comment.
zabbix recommends installing their own packages instead of distro-distributed ones, see https://www.zabbix.com/documentation/7.4/en/manual/installation/install_from_packages
There was a problem hiding this comment.
And please, do the testing yourself and post the results - with i.e. automatus in a custom container implementing Zabbix.
There was a problem hiding this comment.
Thanks @macko1 for pointing that out. Zabbix's own recommendation to prefer their official packages over distro ones is a fair concern, so I tested the rules directly in a custom Debian 13 container configured with the official Zabbix 7.4 repository (repo.zabbix.com), as recommended in their documentation.
./build_product debian13 --rule-id package_zabbix_agent_installed
cd tests
./automatus.py rule --docker ssg_test_suite_debian13_zabbix --product debian13 \
--datastream ../build/ssg-debian13-ds.xml package_zabbix_agent_installed
# -> Script package-installed-removed.fail.sh using profile (all) OK
# -> Script package-removed.fail.sh using profile (all) OK
# -> Script package-installed.pass.sh using profile (all) OKpackage_zabbix_agent_installed only checks that the zabbix-agent package is installed, regardless of which repository it comes from. The official repo keeps the exact same package name, just at a newer version (7.4.15 vs. Debian's packaged 7.0.22). With the default APT priorities, the official Zabbix package is selected because it has a higher version. The remediation log confirms the install actually came from the Zabbix repo:
Get:2 https://repo.zabbix.com/zabbix/7.4/stable/debian trixie/main amd64 zabbix-agent amd64 1:7.4.15-1+debian13 [826 kB]
Setting up zabbix-agent (1:7.4.15-1+debian13) ...
zabbix_agent_server_configured also passes cleanly against this same container (5/5 scenarios, same as previously verified):
cd ..
./build_product debian13 --rule-id zabbix_agent_server_configured
./automatus.py rule --docker ssg_test_suite_debian13_zabbix --product debian13 \
--datastream ../build/ssg-debian13-ds.xml zabbix_agent_server_configured
# -> Script both_configured.pass.sh using profile (all) OK
# -> Script default_values.fail.sh using profile (all) OK
# -> Script directives_missing.fail.sh using profile (all) OK
# -> Script server_default.fail.sh using profile (all) OK
# -> Script serveractive_default.fail.sh using profile (all) OKservice_zabbix_agent_enabled is the one rule I can't get a clean Automatus/Docker result for — but it's not specific to Zabbix or to this rule. The OVAL systemd-unit probe requires access to a running systemd instance through D-Bus. However, Automatus's Docker/Podman backend starts the container with /usr/sbin/sshd -D rather than systemd as PID 1, so the required systemd/D-Bus environment is unavailable. I reproduced the same failure using the project's existing Debian 13 test image, which suggests an environment limitation rather than an issue with the Zabbix rule itself (no Zabbix involved at all in that reproduction):
DBus connection failed, could not identify systemd units.
Happy to test service_zabbix_agent_enabled some other way if you can point me to how service_enabled-templated rules are normally exercised in CI/Automatus for other products.
There was a problem hiding this comment.
Thanks @israel-villar a lot for the effort.
I'd suggest testing with a VM, automatus supports that. Example:
./tests/automatus.py template --libvirt qemu:///session <domain_name> --datastream <datastream> <template>
Let us know if you encounter any issues.
Edit: the zabbix package needs to be installed in the VM.
Server (passive checks) and ServerActive (active checks) are independent Zabbix agent directives; a site may legitimately only use one of them. Narrow zabbix_agent_server_configured to only check Server, and add zabbix_agent_serveractive_configured to check ServerActive on its own. Test scenarios for each rule now also verify the other directive's value doesn't affect the result. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@macko1 Thanks for the suggestion! Tested all three rules with Automatus's libvirt backend against a real Debian 13 VM (systemd, not a container), with the official Zabbix 7.4 repository configured ( cd tests
./automatus.py rule --libvirt qemu:///system debian13-bios --datastream ../build/ssg-debian13-ds.xml package_zabbix_agent_installed
# -> Script package-installed.pass.sh using profile (all) OK
# -> Script package-installed-removed.fail.sh using profile (all) OK
# -> Script package-removed.fail.sh using profile (all) OKConfirmed by SSH after remediation that the official package actually got installed, not Debian's: ./automatus.py rule --libvirt qemu:///system debian13-bios --datastream ../build/ssg-debian13-ds.xml zabbix_agent_server_configured
# -> Script both_configured.pass.sh using profile (all) OK
# -> Script default_values.fail.sh using profile (all) OK
# -> Script directives_missing.fail.sh using profile (all) OK
# -> Script server_default.fail.sh using profile (all) OK
# -> Script serveractive_default.fail.sh using profile (all) OK./automatus.py rule --libvirt qemu:///system debian13-bios --datastream ../build/ssg-debian13-ds.xml service_zabbix_agent_enabled
# -> Script service_enabled.pass.sh using profile (all) OK
# -> Script service_disabled.fail.sh using profile (all) OKSeparately, while looking at
Pushed as ./automatus.py rule --libvirt qemu:///system debian13-bios --datastream ../build/ssg-debian13-ds.xml zabbix_agent_server_configured
# -> Script server_default.fail.sh using profile (all) OK
# -> Script server_configured.pass.sh using profile (all) OK
# -> Script server_missing.fail.sh using profile (all) OK
./automatus.py rule --libvirt qemu:///system debian13-bios --datastream ../build/ssg-debian13-ds.xml zabbix_agent_serveractive_configured
# -> Script serveractive_configured.pass.sh using profile (all) OK
# -> Script serveractive_missing.fail.sh using profile (all) OK
# -> Script serveractive_default.fail.sh using profile (all) OK |
|
Perfect, glad that helped @israel-villar! |
|
@macko1 Done, PR description updated. Thanks for the feedback! |
Description:
zabbixrule group underlinux_os/guide/services/zabbix/with four rules:package_zabbix_agent_installedandservice_zabbix_agent_enabled(both using existing templates), and two custom-OVAL rules that each check one Zabbix agent directive in/etc/zabbix/zabbix_agentd.confindependently:zabbix_agent_server_configured(Server, passive checks) andzabbix_agent_serveractive_configured(ServerActive, active checks). Adds thezabbixcomponent.Rationale:
sebool_httpd_can_connect_zabbix,sebool_zabbix_can_network) but had no rules covering the monitoring agent itself.ServerandServerActiveare independent directives —Servercontrols which hosts may query the agent (passive checks),ServerActivecontrols which server the agent reports to (active checks). A site may legitimately use only one of the two (Zabbix itself recommends active-only for firewall-friendliness), so they are checked by two separate rules instead of one rule requiring both, as originally implemented. Neither rule ships with remediation, since the correct server address is site-specific.Review Hints:
repo.zabbix.com) configured so the remediation pulls the official package instead of Debian's:package_zabbix_agent_installed: all 3 scenarios OK; confirmed by SSH that the officialzabbix-agent/zabbix-releasepackages were actually installed, not Debian's own.service_zabbix_agent_enabled: both scenarios OK.zabbix_agent_server_configured/zabbix_agent_serveractive_configured: all scenarios OK, including cases that verify each rule ignores the other directive's value.linux_os/guide/services/zabbix/*/rule.yml, the twooval/shared.xmlfiles,components/zabbix.yml.