Files

T

wmantly cec0d92c25 feat: real plugin system with loadable instances + OpenBao secrets (v1.17.0)

Generalize the half-built discovery plugins into a real plugin system: plugin
TYPES (the plugins/<category>/<type>.js modules with manifests) and loadable,
configurable, multi-copy plugin INSTANCES (PluginInstance ORM model) managed
from a dedicated /plugins page and /api/plugins API, with per-instance secrets
in OpenBao at secret/plugins/<id>/conf.

- plugin_registry.js: getTypes/getModule/splitConfig/mask + required-field helpers
- PluginInstance model (Sequelize): id/pluginType/category/name/slug(unique)/
  enabled/cron/config(json, non-secret)/lastRun*; registered in models/index.js
- plugin_secrets.js: read/write/remove/mergeForRun over @simpleworkjs/bao-conf
- scheduler.js: schedules from the DB registry; per-instance stable BullMQ
  JobScheduler ids (plugin:<id>) for load/unload; legacy migration from
  conf.discovery.plugins on first boot (idempotent, empty-table-guarded)
- api_plugins.js (replaces routes/plugins.js): types/list/get/create/update/
  secrets/test/load/unload/run/delete/runs; admin-gated; secrets always masked
- /plugins page (plugins.ejs) + nav; Agents & Scheduler tab removed from
  /directory; /docs/agents aliased to /docs/plugins
- proxmox/unifi/nmap gained manifests (configSchema/validate/run alias)
- tests/plugins.test.js: registry unit + plugin_secrets (mocked bao-conf) +
  PluginInstance model round-trip/unique-slug
- docs (plugins.md, vault.md, _config.yml, API.md) + 1.16.1 -> 1.17.0

Requires theta-suite >= v1.30.1 for the sso-broker secret/plugins/* grant;
fails-soft with a clear error if absent.

Co-Authored-By: Claude <noreply@anthropic.com>

2026-08-01 20:33:57 -04:00

2.1 KiB

Raw Blame History

layout, title, nav_order

layout	title	nav_order
default	Secrets Vault	6

Secrets Vault

SSO Manager integrates natively with OpenBao (a Vault fork) to securely manage and store sensitive data, configuration, and API keys.

The Vault proxy endpoint is exposed directly through SSO Manager at /api/vault/v1/, which safely authenticates and authorizes requests before forwarding them to the internal OpenBao container.

Architecture

The secrets engine uses a persistent file backend (/var/lib/docker/volumes/theta-env_openbao-data/_data) to ensure high availability and durability.

When the environment is initialized via setup.sh, OpenBao is automatically unsealed and seeded with a root token that the application uses for authentication. The root token is kept securely inside the container environment.

Accessing the Vault

The SSO Manager Vault can be accessed in two ways:

Via the SSO Manager UI: Go to the Admin Configuration page (/conf) to edit the application's configuration secrets directly.
Via the REST API: Send requests to /api/vault/v1/... with your SSO Manager session or API Token.

API Example

To read secrets from the default key-value store, issue a GET request to: /api/vault/v1/secret/data/sso-manager/conf

Only administrators with app_sso_admin or admin permissions can query the vault endpoints.

Namespaces and Paths

Currently, secrets are maintained at /v1/secret/data/sso-manager/conf using the kv-v2 backend. When configurations are edited via the admin UI, SSO Manager performs a deep-merge so that partial updates don't overwrite unrelated keys (such as SMTP vs OAuth configurations).

Plugin Integration

Plugin instances store their per-instance secrets in OpenBao at secret/plugins/<instance-id>/conf (configured, loaded/unloaded, and run from the Plugins page — see Plugins). The plugin process runs in-process, so the SSO Manager reads/writes those secrets server-side through the sso-broker token; the admin UI only ever sees masked values, and external apps can retrieve API tokens via the /api/vault proxy to keep permissions consistently enforced instead of hardcoding them.

2.1 KiB Raw Blame History