Integrate Wazuh SIEM

[runleveldev]

We should integrate Wazuh (or another OSS SIEM) with the cluster. The old cluster had an issue regarding duplicate agent names since people would often re-create containers with the same hostname, which we need to avoid. I also want to avoid hard-coding the Wazuh manager's hostname/IP address into the container image/provisioning script. Finally, support for a properly configured, external Wazuh server would be nice for future use where we would want a central SIEM for multiple sites.

I picture this being implemented as follows:

1. Two new images/, one for the "compute" layer and one for the "storage" layer. I'm not an expert on Wazuh architecture, so if those layers can't be cleanly separated 1 is fine. (The logic for 2 is to deal with upgrades, I can go into more detail if you want).
2. These image(s) should be built on top of base and be able to fully configure a Wazuh system via only environment variables (the motto is "no SSH-ing in"). SSSD should potentially be restricted to the sysadmins group. Ideally the Wazuh manager is configured to allow login via the ldap servers but an admin password set via env var is acceptable for an MVP.
3. Wazuh should be configured to remove inactive agents (in the config if possible, but API based cron would be fine). This is to avoid needing the create-a-container needing to delete agents along with the actual container, so if we can't do automatic agent cleanup we'll need to do that instead. Maybe via https://documentation.wazuh.com/current/user-manual/agent/agent-management/remove-agents/restful-api-remove.html#removing-disconnected-agents
4. A "Wazuh API URL" setting in the create-a-container database (using the Settings model). This creates a one-to-one mapping where each cluster manager works with exactly one Wazuh manager.
5. A link on the sidebar that opens the Wazuh URL (preferably in a new tab) that should only appear if set in the settings.
6. The create-container.js job should be updated to pass the Wazuh URL to the containers via environment.
7. A systemd service should be added to run on first-boot (see container-creator-init.service from create-a-container for reference) which registers the agent with the configured URL. I'd like to use /etc/machine-id as a stable, randomly generated identifier rather than hostname to avoid the conflicting agent name problem from the older cluster. We can use agent_name in the configuration.
8. Since the manager will likely be publicly accessible, password authentication for agent enrollment may be required. The password can be set via environment variable in create-container.js and stored in the Settings model along with the URL. Not sure how we can prevent leaking this password when users have sudo on their own containers. https://documentation.wazuh.com/current/user-manual/agent/agent-enrollment/security-options/using-password-authentication.html

[runleveldev]

Technically only steps 4-7 above are required for MVP. Steps 1-2 are for bootstrapping if we don't have a Wazuh (we don't but I'm fine with a manual install for now). Step 3 is just a configuration that should at least be documented in the Admins section of the documentation. Steps 2 and 8 can be considered stretch goals. If 8 is not completed we should open a follow up ticket to implement it before this is considered production-ready (a long way off yet).

[cmyers-mieweb]

Created new branch, https://github.com/mieweb/opensource-server/tree/cmyers_issue210

Adds the following features:
Feature 1: Custom Tools
New tables: CustomTools, CustomToolGroups (junction)

Settings → Custom Tools (/custom-tools): Admin-only page to add/edit/delete named URL links with per-tool group visibility control. Multi-select dropdown lets you choose which groups can see each tool.
Sidebar: Users automatically see tools in the nav sidebar for any tool where their group is in the visibility list. Tools open in a new tab with an external link icon. Admins see the management links regardless.
Group IDs are now stored in the session at login so the sidebar can filter tools without a per-user DB query on every request.
New files: models/custom-tool.js, models/custom-tool-group.js, routers/custom-tools.js, views/custom-tools/index.ejs, migrations/20260310000000-create-custom-tools.js

Feature 2: Per-Container One-Shot Commands
New column: Containers.oneShotCommands (TEXT, JSON array)

Create Container form: A new "Custom One-Shot Commands"

Details

section (only on new container creation, not edit) with a text area where you enter one bash command per line.
Commands are stored as a JSON array on the container record and run inside the container after it starts, after global commands.

Feature 3: Global One-Shot Commands
New table: GlobalOneShotCommands

Settings → One-Shot Commands (/global-oneshot-commands) Admin-only page to manage named bash commands with an enabled/disabled toggle. These run in every new container.
Execution order: Global commands run first (in creation order), then per-container commands. Failures are logged but non-fatal — container creation continues.
Commands execute via the Proxmox API's /exec endpoint: bash -c "".

[cmyers-mieweb]

[cmyers-mieweb]

[cmyers-mieweb]