:PROPERTIES:
:ID:       b396f72b-8f82-427e-97e4-07bf5fa1a974
:END:
#+title: Zabbix - HC related decissions
#+include: ~/org/templates/document_article.org

* ADR-0001 - Zabbix Proxy Configuration - RemoteCommands (control 1045)

| *ID*      | ADR-0001                                                   |
| *Subject* | Zabbix Proxy Configuration - RemoteCommands (control 1045) |
| *Status*  | Proposed                                                   |
| *Date*    | 2026-02-26                                                 |

** Problem statement
*** Settings recommended by Kyndryl
"SM1.1.4.1
The RemoteCommands parameter in <proxy_configuration_file> controls whether the Zabbix Proxy accepts remote commands from the Zabbix Server.

RULES:
RemoteCommands must be disabled unless explicitly required and approved for a documented business need.
Enabling remote commands significantly increases security risk and must be carefully controlled.
In <proxy_configuration_file>:
RemoteCommands=0 → disables remote commands.
If the parameter is absent, the default behavior also disables remote commands."

*** Agreed to setting
"In <proxy_configuration_file>:
RemoteCommands=0 → disables remote commands.
If the parameter is absent, the default behavior also disables remote commands."

*** HC Implementation details :notoc:
"Ensure RemoteCommands=0 or parameter omitted in zabbix_proxy.conf.
Audit all included config fragments for any RemoteCommands=1 and remove.
Restart Proxy and verify via logs that remote commands are disabled."

** Alternatives

| ID | Description                                                                                | Pros                                                                                    | Cons                                                                                                                                |
|----+--------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------|
|  1 | Implement the Kyndryl proposed settings                                                    | Compliant with SM1.1.4.1; reduced attack surface; no additional approval needed         | Breaks existing monitoring for items without native templates; requires migration effort to replace all remote command-based checks |
|  2 | Do not implement the Kyndryl proposed settings                                             | No disruption to existing monitoring; maintains coverage for non-template items         | Non-compliant without formal exception; increased security risk; requires approved exception document                               |
|  3 | Migrate non-template checks to UserParameters or system.run[], then disable RemoteCommands | Compliant after migration; preserves monitoring coverage; uses least-privilege approach | Migration effort and testing required; temporary risk window during transition; ongoing maintenance of UserParameter configs        |

** Decision
Option 2 — Maintain EnableRemoteCommands=1 on Zabbix proxies and request a formal security exception to SM1.1.4.1 with documented business justification.
** Justification
Custom monitoring templates use =system.run[]= item keys on agents (configured via =AllowKey=system.run[*]=) for checks where no native Zabbix template exists. The number of affected custom templates is significant, and migration would not be limited to rewriting the templates themselves — it would also require reconfiguring AllowKey directives and deploying UserParameter definitions on every affected agent, followed by agent restarts across the entire monitored environment. These items are collected through Zabbix proxies, and action-based remote commands for automated remediation are also forwarded through proxies. Disabling =EnableRemoteCommands= on proxies would break both data collection and automated remediation workflows.

From a cost-effectiveness perspective, this is legacy infrastructure with an officially planned end-of-life at the end of 2026. Investing significant effort into a full migration of custom templates and agent reconfiguration for an environment that will be decommissioned within the year is not justified. The effort-to-benefit ratio strongly favors maintaining the current setup for the remaining operational period.
** Implications

All existing checks that rely on RemoteCommands must be inventoried and catalogued before migration begins. Each check needs to be converted to a UserParameter entry (or AllowKey directive in Zabbix Agent 2) deployed to the relevant hosts. Testing must confirm equivalent alerting behavior before RemoteCommands is disabled. Configuration management (Ansible/Puppet) must distribute the new UserParameter files consistently. A transition timeline with a defined cutover date should be agreed with Kyndryl.
A formal security exception request must be submitted to Kyndryl with documented business justification referencing this ADR. The exception must include a list of affected proxies and the scope of =system.run[]= usage. The exception should be time-bounded by the planned infrastructure end-of-life at end of 2026. =LogRemoteCommands=1= should be enabled on agents where not already active to provide an audit trail supporting the exception request.
** Derived requirements
- DR-001: Submit formal exception request to Kyndryl for SM1.1.4.1, referencing this ADR and the business need for =EnableRemoteCommands=1= on proxies.
- DR-002: Include the planned infrastructure end-of-life (end of 2026) as the exception expiration date.
- DR-003: Inventory all =system.run[]= items and document which custom templates depend on this mechanism.
- DR-004: Enable =LogRemoteCommands=1= on all Zabbix agents to maintain an audit trail of executed remote commands.