Skip to main content

What Fleet can and cannot do

Fleet does not read your Wazuh deployment and does not write to it. The connector on your host relays no queries to the indexer or the Wazuh server API, probes neither of them, and performs no writes. The one thing about Wazuh the connector handles is the login the installer finds on a Wazuh node, which it hands to the services installed on that host and never sends to Fleet. What Fleet knows is which hosts you have, whether each one is online, and what the Fleet services you enable on them report about themselves. This page is the exact statement of that boundary.

What crosses the wire​

The connector holds one outbound mTLS session to Fleet. Two things travel on it:

  • Out: a heartbeat every 30 seconds, carrying the connector's id and version, the host's name, operating system, distribution, architecture and kernel, and the status of each Fleet service running on it. Nothing about your Wazuh data, and nothing about the machine beyond those facts: no CPU, no disk, no process list.
  • Back: Fleet's answer to the heartbeat, which may ask the host to install or remove a service and to move to a newer connector version. Nothing else.

There is no request path from Fleet to your indexer or Wazuh server API at all. The console holds no Wazuh credentials, and the connector opens no Wazuh connection of its own, so a compromise of Fleet cannot read or change your deployment: there is no relay to ride.

The credentials stay on the host​

When the installer runs on a Wazuh node it looks, once, for the login Wazuh keeps there, reading files only, and the connector hands it only to the services installed on that host through Fleet. On 4.x that is the indexer login the manager ships alerts with. On 5.x it is the dashboard's own service account, which reads every Wazuh data index but not the CTI status. The running connector discovers nothing itself. A service can also ask for its login in its own console and hand it to its plugin with the enrolment token, and that login replaces the one the installer found. Either way the plugin reaches its own upstream directly, inside your network, and keeps the login under its own account on that machine. Nothing about Wazuh is written into the connector's own configuration, /etc/fleet-connector/connector.yaml, and no login travels to Fleet. See The Wazuh login the installer finds. See Connector configuration.

Active Response is not Fleet's​

Active Response is configured from Mobius now, not from Fleet. An active_response block left in the connector's configuration does nothing: it is parsed so an older file still loads, and the connector logs once that the block can be removed. Installing with --active-response or --no-active-response is refused.

Running a service is the one thing that touches the host​

The connector can install a Fleet service on the host and grant it a system user (and, only when the machine owner's own file says so, a root shell). That is installing software on a machine you control, on your instruction from the console, not a way for Fleet to read or change Wazuh. Handing that service the login the installer found is part of the same act, on the same host. See Connected services for what a service is and how you enable one, and Data handling for what Fleet stores.

Reading a deployment would be a separate decision​

Fleet does not read the deployments a connector sits beside. Finding the login a Wazuh node keeps is not reading the deployment: the installer never signs in with it, and Fleet never receives it. Making Fleet able to read or change them is not an incremental feature and will not arrive as one. It would be a separate decision, with its own risk conversation, its own approval model and its own audit trail, because it changes what a compromise of Fleet is worth. Nothing in the current design is a partial step towards it.