Wazuh Google Cloud monitoring

The core decision is which collection path the Wazuh Google Cloud module uses for each log type you plan to collect. A Pub/Sub subscription delivers events to the Wazuh server as they are published, so alerts can follow activity closely. A Cloud Storage bucket holds exported log files that the server reads on a schedule, so events arrive in batches tied to the export and read cycle. Before you choose, confirm in the Wazuh documentation for the Google Cloud module which path it supports for each log type. Some log types may offer only one path, which settles the question for them, and the choice then applies only to the types that offer both.

Latency and replay pull in different directions. Pub/Sub suits fast detection, such as changes to IAM policies or firewall rules, but messages are held only for the subscription's retention period and are redelivered until they are acknowledged. Confirm that retention period in Google Cloud documentation, and confirm when the Wazuh integration acknowledges a message, which should happen only after the server has processed it. The bucket path keeps the source files themselves, so you can reprocess a time window after a decoder or rule change or after a collection outage. The trade-off is delay, which depends on how often the export writes files and how often the server reads them.

Retention and IAM scope differ between the two paths. In the bucket path, retention is governed by your own object lifecycle and retention settings, so decide how long exported files must remain for incident response and audit evidence before you enable the export. Those files add storage cost that recurs for as long as they are kept. On the identity side, the Wazuh credential for Pub/Sub needs rights to consume from one subscription, while the credential for the bucket path needs read access to objects in one bucket. Scope each credential to the single topic, subscription or bucket involved, and check the exact roles the module documents instead of granting broad project-level roles.

Cost drivers differ by path. Pub/Sub charges relate to message throughput and delivery volume, so a noisy log source drives cost up directly. Cloud Storage charges relate to stored bytes, object operations and any network egress if the reader runs outside the bucket's region. Export volume affects both, so measure it for each log type before you commit. Ask Google Cloud for current pricing in writing, and check your own billing data during a trial period, rather than relying on published examples. On the Google Cloud side, the Pub/Sub path needs a log sink that routes entries to a topic and a subscription the Wazuh credential can read. The bucket path needs a sink that writes files to the bucket and a reader identity that can list and read those files.

Before you request a quote, work through a short checklist: list every Google Cloud log type in scope, confirm the supported path for each in the Wazuh documentation, set the latency and replay requirement per type, decide who owns retention for exported files, map the least-privilege roles for each credential, and measure expected export volume with the team that owns the Google Cloud logging configuration. A written scope that records these decisions makes the quote comparable across partners and shows where the work and the recurring costs will come from.

Module collection and Wazuh agents answer different questions, so a team usually needs both. The Google Cloud collection path reads what Google Cloud records about the control plane and managed services: audit activity from Cloud Audit Logs, configuration changes, and service-level events that arrive through Pub/Sub or a Cloud Storage bucket. An agent on a virtual machine records what happens inside that machine: file integrity changes, running processes, local system and application logs, and the software inventory that feeds vulnerability detection. A deleted firewall rule shows up in the cloud logs. A new listening process or a modified configuration file on the instance shows up only through the agent.

Decide the split before either build starts. Map each event type you need to detect to the source that can see it, then list the instances that hold regulated data, administrative credentials or internet-facing services. Those instances are the candidates for agents. Lower-risk workloads, such as short-lived build runners or disposable test machines, may be covered adequately by cloud logs alone, but that is a risk acceptance your security owner should record in writing. Agent coverage on a large fleet also carries operating cost in upgrades, configuration management and endpoint resources, so the list should be justified by data and risk rather than by the number of machines.

Expect overlapping alerts. A single action can appear in both sources: an administrator who changes a firewall rule creates a Cloud Audit Log entry, and if the same administrator then logs in to the instance and edits a local file, the agent records a separate event. Correlation rules that group by user, instance name or time window reduce noise, but they depend on consistent identifiers across the two sources. Check that the instance names and labels in the cloud logs match the agent names in Wazuh, and test a known change in a non-production project to confirm which events reach the dashboard and how they are grouped.

Agent deployment is a separate piece of work. It needs its own enrollment, group assignment and configuration for each operating system, along with the Wazuh server reachable from the instances, and firewall rules that allow agent traffic. Confirm the agent version supported for each operating system in the Wazuh documentation before you plan the rollout, and confirm how agent configuration and upgrades will be managed centrally. The cloud log integration and the agent rollout should be scoped, scheduled and tested as two deliverables so that a delay in one does not hide gaps in the other.

The goal of this test is to show, layer by layer, that a Google Cloud event travels from its source to a visible Wazuh alert, so that a failure can be located instead of guessed at. Run the three layers in order and do not move to the next layer until the one below it passes. The first layer confirms that the service account authenticates and can read the source, either the Pub/Sub subscription or the Cloud Storage bucket the module uses. Test with the same credentials and the same read permissions the production configuration uses. A successful read with a broader test identity can hide a missing grant, so the permissions should match exactly. Confirm the required roles in the release documentation before you start.

The second layer proves that a known event reaches the Wazuh server and indexer. Perform a controlled audit action in the test project, such as creating and then deleting a test Cloud Storage bucket with a unique name, and record the exact time and the name you used. Then search for that name on the Wazuh server output and in the indexer. The event should appear decoded, with its fields mapped to named values instead of appearing as an undifferentiated JSON string. If the event reaches the indexer but not the server output, suspect the decoder or the rule set. If it appears nowhere, check the authentication and subscription state first. Confirm the log file locations, archive settings and search steps for your release in the official documentation, because they change between versions.

The third layer confirms what the analyst sees. Open the Wazuh dashboard and check that the event shows the expected fields, such as the project identifier, the method name, the acting principal and the resource name. Then confirm that a rule fires for a chosen test condition, for example a rule that matches a bucket deletion or an IAM policy change in the test project. Record the rule identifier, its severity level and the alert group. Confirm the rule identifiers and the built-in rules for the Google Cloud module in the release documentation or in the rule files on your server instead of relying on the identifiers shown here, which may change in later releases.

Check for dropped events by comparing counts: the number of test actions you performed against the number of matching events in the indexer for the same time window. Look at the Pub/Sub subscription for unacknowledged messages and at any dead-letter topic you configured, and scan the server logs for parsing or decoder errors around the test time. To measure ingestion lag, subtract the action time from the time the event first becomes searchable in the indexer. Repeat the test several times at different times of day and record the spread of values, not a single measurement. Then record each run for change control: the test identifier, the release version, the identity used, the test resource names, expected and actual results, lag measurements, and the name of the person who signed off. Keep the test resources and the test identity under the same review as the production configuration.