Skip to main content

Install the sidecar

The sidecar is a small read-only connector that runs beside a Wazuh deployment. Over an outbound connection it reports the packages the fleet runs, the vulnerability findings Wazuh has already made, an agent count, and the alert values worth checking against the corpus. Nothing is installed on a manager, nothing writes to the customer's cluster, and every credential it is given is read-only.

The one command​

Run this on the Wazuh node:

curl -fsSL https://dl.pharos.wazuh.com/install.sh | sudo sh -s -- --key=phe_...

The --key value is an enrolment key, minted on the console's Managers page. The installer works locally and outbound-only:

  1. It downloads the static binary for the platform and verifies its checksum against the published SHA256SUMS. Without a checksum it refuses to install.
  2. It reads the local Wazuh install to find the indexer address and its certificate authority. No guessing, and no insecure default.
  3. It writes the configuration to /etc/pharos-sidecar.env, readable by root only.
  4. It probes the cluster and prints what the cluster can answer.
  5. It installs and starts a systemd unit.

The indexer credential is asked for, never created, because creating one would be a write to the customer's cluster. On Wazuh 5.0 the shipped wazuh-readonly role is enough. On Wazuh 4.x there is no shipped read-only account, so an admin creates a dedicated one first.

--probe-only downloads, detects, probes and prints, and enrols nothing. --uninstall removes everything the installer put on the host.

What never leaves the network​

The sidecar classifies every value on the node, before anything is queued. Private address space, loopback and link-local addresses, the other reserved ranges, and internal name suffixes such as .local, .internal, .corp and .lan are dropped on the spot. The alert fields it reads are a short, explicit list rather than a whole-document sweep, which is what keeps internal hostnames and employee addresses out of the queue by construction.

The local cache stores digests rather than values, so a state file attached to a support ticket carries no record of what the fleet's hosts connected to.

The enrolment key​

A key is shown once and stored hashed. One key admits any number of managers, and connecting a manager carries no fee.

Enrolment exchanges the key for a per-deployment credential, and that credential is what every later request uses, so rotating a key does not disturb a sidecar that is already enrolled. Keys are minted, rotated and revoked on the Managers page.