Charm architecture

The charm design leverages the sidecar pattern to allow multiple containers in each pod with Pebble running as the workload container’s entrypoint.

If you run kubectl get pods on a namespace named for the Juju model you’ve deployed the Wazuh server charm into, you’ll see something like the following:

NAME                             READY   STATUS    RESTARTS   AGE
wazuh-server-0                    2/2     Running   0         6h4m

This shows there are 2 containers:

1. A Wazuh server container, which has Wazuh server installed and configured alongside several collectors and Filebeat to ingest and export logs.
2. A sidecar containing Pebble: a lightweight, API-driven process supervisor that is responsible for configuring processes to run in the workload container and controlling those processes throughout the workload lifecycle.

OCI images

We use Rockcraft to build the OCI image for Wazuh server. The image is defined in Wazuh server rock and is published to Charmhub, the official repository of charms. This is done by publishing a resource to Charmhub as described in the Charmcraft how-to guides.

Wazuh server

Wazuh server is an application controlled by the /var/ossec/bin/wazuh-control script. Alongside it, several collectors and a filebeat instance is deployed to ingest and export the logs.

The Wazuh server listens on ports:

• 1514 and 1515: for the Wazuh agents to connect;
• 55000: to access Wazuh’s API.

The collectors deployed are:

• rsyslog, which listens on port 6514 for remote servers to send logs over TLS;

C4Context
title Wazuh reference architecture

Container_Boundary(wazuh-server-container, "Wazuh container") {
  Component(wazuh-filebeat, "Wazuh filebeat", "", "Forwards logs")
  Component(wazuh-server, "Wazuh server", "", "Analyzes logs and events")
  Component(wazuh-rsyslog, "Wazuh rsyslog server", "", "Collects logs")
}

Boundary(storage, "Storage") {
  ComponentDb(filesystem, "Ephemeral storage", "", "Logs files on filesystem")
}

Rel(wazuh-rsyslog, filesystem,"")
Rel(filesystem, wazuh-server,"")

The workload that this container is running is defined in the Wazuh server rock.

Storage

The Wazuh server charm mounts a filesystem type storage to store the incoming rsyslog logs and any other data that requires persistence across container restarts.

Charm code overview

The src/charm.py is the default entry point for a charm and has the WazuhOperatorCharm Python class which inherits from the CharmBase.

CharmBase is the base class from which all Charms are formed, defined by Ops (Python framework for developing charms).

See more information in Charm.

The __init__ method guarantees that the charm observes all events relevant to its operation and handles them.

Take, for example, when a configuration is changed by using the CLI.

1. User runs the command

juju config wazuh-server custom-config-repository=git+hhtp://github.com/sample-repository.git

2. A config-changed event is emitted
3. Event handlers are defined in the charm’s framework observers. An example looks like the following:

self.framework.observe(self.on.config_changed, self._on_config_changed)

4. The method _on_config_changed will take the necessary actions. The actions include waiting for all the relations to be ready and then configuring the container.