Skip to main content

Overview

Wazuh Dashboard Plugins are built on the OpenSearch Dashboards plugin platform, which provides a standardized lifecycle and dependency management system. Each plugin is a self-contained module with defined setup, start, and stop phases.

Plugin Lifecycle

Every plugin implements a consistent lifecycle with three main phases:
1

Setup Phase

Occurs during OpenSearch Dashboards initialization. Plugins register routes, UI applications, and configure integrations.
2

Start Phase

Runs after all plugins have completed setup. Services become available, background jobs start, and the plugin is fully operational.
3

Stop Phase

Called during shutdown to clean up resources, close connections, and terminate background processes.

Plugin Manifest

Each plugin declares its metadata, dependencies, and capabilities in opensearch_dashboards.json:

The Three Core Plugins

1. wazuh-core: Foundation Services

The core plugin provides essential services used by other plugins.

Public Plugin (Browser)

File: plugins/wazuh-core/public/plugin.ts
Services Provided:

Configuration

Multi-provider configuration management with UI settings and initializer context

Dashboard Security

Security platform detection and integration utilities

Utilities

Shared helper functions and constants

Hooks

React hooks for accessing core services

Server Plugin (Node.js)

File: plugins/wazuh-core/server/plugin.ts
Key Components:

2. wazuh-check-updates: Update Notifications

A lightweight plugin for managing update notifications. File: plugins/wazuh-check-updates/public/plugin.ts
Exports:
  • UpdatesNotification: UI component for displaying update banners
  • DismissNotificationCheck: Component to check dismissal state

3. wazuh (Main): Complete Security Platform

The main plugin provides all user-facing features and security modules.

Public Plugin

File: plugins/main/public/plugin.ts
Application Structure: Each application registered by the main plugin represents a security module:

Server Plugin

File: plugins/main/server/plugin.ts

Health Check System

The main plugin’s server implements extensive health checks during setup:

Index Pattern Health Checks

Example from plugins/main/server/plugin.ts (lines 261-296):
The system registers health checks for:
  • System Activity Events
  • Security Events
  • Access Management Events
  • Applications Events
  • Other Events
  • Network Activity Events
  • Cloud Services Events (Generic, AWS, Azure, GCP)
  • Vulnerabilities
  • FIM (Files, Registry Keys, Registry Values)
  • SCA (Security Configuration Assessment)
  • Inventory (System, Hardware, Networks, Packages, Ports, Processes, Protocols, Users, Groups, Services, Interfaces, Hotfixes, Browser Extensions)
  • Monitoring (Agent status and metrics)
  • Statistics (Server performance data)
  • Connection compatibility
  • Run-as configuration validation
  • Required dashboards and visualizations

Plugin Dependencies

Dependency Graph

Required vs Optional Dependencies

Must be present for plugin to load:All plugins require:
  • navigation - Menu and navigation services
  • opensearchDashboardsUtils - Common utilities
Main plugin additionally requires:
  • data - Search and aggregations
  • dashboard - Dashboard embedding
  • discover - Event exploration
  • visualizations - Chart rendering
  • charts - Chart configuration
  • savedObjects - Saved object management
  • wazuhCore - Foundation services
  • wazuhCheckUpdates - Update notifications

Service Architecture

Public Services (Browser)

Services are made globally available through module-level setters:
Benefits:
  • Avoid prop drilling through deep component trees
  • Access platform services from any component
  • Testable through service mocking

Server Services (Node.js)

Services are provided through request context:

Plugin Communication

Plugins communicate through:

Direct API

Setup/start return values expose services to dependent plugins

Shared Context

Request context provides scoped service access

Events

Core event bus for lifecycle and state events

HTTP API

REST endpoints for cross-plugin communication

Development Workflow

Creating a New Plugin

1

Create Plugin Structure

2

Add Manifest

Create opensearch_dashboards.json with plugin metadata
3

Implement Plugin Classes

Create public/plugin.ts and server/plugin.ts
4

Export Plugin

Create public/index.ts and server/index.ts
5

Build and Test

Plugin Development Best Practices

Avoid These Anti-Patterns:
  • Don’t access services before they’re initialized
  • Don’t create circular dependencies between plugins
  • Don’t bypass the plugin lifecycle (setup → start → stop)
  • Don’t store request-specific data in plugin instance variables
Follow These Patterns:
  • Use TypeScript interfaces for plugin contracts
  • Implement proper error handling in all lifecycle methods
  • Clean up resources in stop() method
  • Use dependency injection for testability
  • Keep plugins focused on single responsibilities

Architecture

Overall system architecture and design

Security Modules

Implemented security and monitoring features

Data Sources

Index patterns and data organization

Development Guide

Set up your development environment