Files

T

wmantly e8d04203c3 fix: group names match docs, dedupe resource groups, agent 404, shared-secrets + vault apps, promote + plugin logs (v1.27.0) (#168 )

- group names match docs/GROUPS.md: {site}_{kind}_{name}_{level} (kind always present; services -> app kind); updated resolver + tests + access_request test
- site resource carries only god_admin + site-wide groups
- groups no longer appear 3x: idempotent ResourceGroup linking (self-heal was creating duplicates on every Directory load)
- /api/agent/* no longer 404s: REST router mounts unconditionally (was gated on the WS server)
- shared-secrets: slug regex allows underscores; GET list uses static pathFor (fixes 's.path is not a function')
- vault Apps tab: new GET /api/vault/apps + Minted apps list + purpose text; /docs/vault help link + docs cover Apps/Shared
- discovery promote: load instance and call update() (fixes 'Resource.update is not a function')
- discovery plugin cards: last-run time/status + Logs button

2026-08-04 23:00:25 -04:00

3.0 KiB

Raw Blame History

Vault Secrets Management

The Vault Secrets feature integrates with OpenBao to provide a secure key-value store for your environment. It allows you to store sensitive information like passwords, API keys, and credentials, ensuring they are encrypted and access-controlled.

Usage

You can access the Vault UI from the application's top navigation bar.

Creating Secrets

Click on the New Secret button.
Enter a Secret Path. This acts as the name/identifier of your secret (e.g., db-credentials).

Enter the Secret Data in JSON format. For example:

{
  "username": "admin",
  "password": "supersecretpassword123"
}

Click Save Secret.

Reading and Editing Secrets

To view a secret, click on its name in the Secrets List.
To update an existing secret, select it and click the Edit button. You can then modify the JSON data and save your changes.

OpenBao Integration

The secrets are stored in an OpenBao backend configured in development mode. The default KV (Key-Value) version 2 engine is mounted at secret/. The built-in UI uses the /api/vault/secret/ API endpoints to interact with OpenBao.

Apps tab (admin)

The Apps tab mints a scoped OpenBao token for an external application so it can read its own configuration out of OpenBao — a downstream-app credential, not a per-user secret.

Enter an app name (e.g. my-service) and click Mint token.
A token is shown once — copy it into the external app now; it cannot be recovered later. The app uses it as the X-Vault-Token header against secret/apps/<name>/* (see the connection convention shown on the page).
The Minted apps list shows every token you've created (metadata only — the token itself is never stored). sso keeps each token alive by renewing it periodically, so a downstream app's credential stays valid as long as sso runs. If an app shows a renewal error, re-mint it here — that revokes the old token and issues a fresh one.

The token is scoped to secret/apps/<name>/* only (policy app-<name>), so a compromised token can't touch any other secret.

Shared tab

The Shared tab lets you share a secret with another user (or app) without copying the value around.

New — give the secret a name (slug) and its JSON data. The owner has full read/write on secret/shared/<uid>/<slug>.
Open a secret and use Grants to share it with a user or app; the grantee's OpenBao policy is edited immediately so the share takes effect with no token re-mint. Revoking a grant removes access at the ACL.
The data itself is read through the normal Vault proxy using each user's own session, so OpenBao enforces read access per-request.

API Access

If you need to programmatically access the secrets, you can interact directly with the OpenBao API using the root token (in dev mode):

# Example: Read a secret via the API
curl -H "X-Vault-Token: root" -H "Authorization: Bearer <your-sso-token>" http://<your-sso-host>/api/vault/secret/data/<your-secret-path>

3.0 KiB Raw Blame History