--- id: HF-WP-0002 type: workplan title: "Expose OpenBao Browser UI at bao.coulomb.social" domain: helix_forge repo: helix-forge status: finished owner: codex topic_slug: openbao-browser-ui created: "2026-06-15" updated: "2026-06-19" planning_priority: high planning_order: 2 related_repos: - railiance-platform - net-kingdom - key-cape - inter-hub - ops-hub related_workplans: - HF-WP-0001 state_hub_workstream_id: "c1b5f54d-2f26-453d-966c-6353df0b6aec" --- # Expose OpenBao Browser UI at bao.coulomb.social ## Goal Make OpenBao usable through a browser at: ```text https://bao.coulomb.social ``` The operator should be able to open the OpenBao UI, authenticate through KeyCape at `kc.coulomb.social`, use the `platform-admin` OpenBao role, and inspect available secret paths without installing a local `bao` CLI. This work directly unblocks the `HF-WP-0001` operator-key path by giving the operator a safer, lower-friction way to inspect whether an Inter-Hub operator key already exists and to store display-once keys created during bootstrap. ## Context Current OpenBao posture, based on local Railiance and NetKingdom runbooks: - OpenBao is deployed in Kubernetes namespace `openbao`. - The service is internal-only today; operators use `kubectl exec` or port-forwarding. - OpenBao UI callbacks are not currently registered because public UI exposure had not been designed. - KeyCape already owns the OIDC login side at `kc.coulomb.social`. - The current CLI OIDC client supports localhost callbacks for `bao login`, but that requires a local `bao` binary and is too much friction for routine operator inspection. Desired new posture: - `bao.coulomb.social` exposes the OpenBao UI over HTTPS. - Browser login redirects to KeyCape and returns to OpenBao UI at: ```text https://bao.coulomb.social/ui/vault/auth/netkingdom/oidc/callback ``` - UI access maps to the existing `platform-admin` policy through the KeyCape-backed `netkingdom` OIDC path. The earlier `keycape` path remains a compatibility alias while operators move to the clearer mount name. - OpenBao remains a privileged platform-secret surface, not a general public application. Exposure must be TLS-only, audited, MFA-backed, and restricted by identity and preferably by network boundary. ## Security Boundary Exposing the OpenBao UI also exposes the OpenBao API surface at the same host. This work must not turn OpenBao into an unaudited or broadly reachable public secret-management console. Minimum controls: - HTTPS only, using a valid certificate for `bao.coulomb.social`. - Authentication through KeyCape/OIDC with MFA for the admin identity. - `platform-admin` policy, not root, for normal operator login. - File audit remains enabled and visibly records authenticated UI activity. - Root token remains revoked or break-glass only. - No OpenBao tokens, Inter-Hub keys, OIDC client secrets, unseal shares, or secret values are committed to Git, State Hub, chat, or workplan text. Preferred controls: - Network restriction by VPN, office IP allowlist, or equivalent admin ingress boundary. - Explicit decision on whether `bao.coulomb.social` is temporary bootstrap exposure or a durable operator surface. - A short runbook that tells operators how to list metadata paths without accidentally revealing secret values. ## Proposed Implementation 1. Add DNS for `bao.coulomb.social` to the Railiance/OpenBao ingress target. 2. Add or update the Railiance Platform OpenBao ingress manifest or Helm values so the OpenBao UI service is exposed at `bao.coulomb.social`. 3. Add the OpenBao UI redirect URI to the KeyCape OpenBao admin client. 4. Add the same URI to the OpenBao `auth/netkingdom/role/platform-admin` `allowed_redirect_uris`, keeping `auth/keycape` as a compatibility alias unless explicitly retired later. 5. Verify browser login end to end with the approved platform-root/operator identity and MFA. 6. Verify metadata-only inspection of candidate paths such as: ```text platform/ platform/operators/ platform/operators/inter-hub/ ``` 7. Store or retrieve the Inter-Hub operator key only through the approved secret path. ## Tasks ### T01 - Decide Browser UI Exposure Boundary ```task id: HF-WP-0002-T01 status: done priority: high state_hub_task_id: "6f516f34-40c1-4e39-a779-3fc7ff503e30" ``` Confirm whether `bao.coulomb.social` is a temporary bootstrap-only operator surface or a durable admin surface. Decide the minimum network boundary: public Internet with MFA only, IP allowlist, VPN-only, or another protected admin ingress pattern. Done when the chosen exposure model is recorded with the accepted risk and owner. Decision on 2026-06-15: expose OpenBao UI/API at `https://bao.coulomb.social` via Traefik ingress, TLS with `letsencrypt-prod`, KeyCape/OIDC MFA login, `platform-admin` role only, HSTS/rate-limit middleware, and no root-token browser use. This is approved as an operator surface for bootstrap and routine metadata inspection, not as a general public application. --- ### T02 - Expose OpenBao UI at bao.coulomb.social ```task id: HF-WP-0002-T02 status: done priority: high target_repo: railiance-platform state_hub_task_id: "41e52213-0a1e-417c-a4d0-5db5141b600d" ``` Implement DNS, TLS, and ingress for: ```text https://bao.coulomb.social ``` The route should target the existing OpenBao UI service and preserve internal service naming. Include any network restriction middleware or ingress annotations selected in T01. Done when the URL reaches the OpenBao UI over valid HTTPS and unauthenticated users cannot access secrets. Code progress on 2026-06-15: `railiance-platform/helm/openbao-values.yaml` now declares the `bao.coulomb.social` Ingress with `letsencrypt-prod`, Traefik, active service routing, and the approved middleware annotations. `railiance-platform/helm/openbao-middleware.yaml` defines the HSTS and rate-limit middlewares, and `make openbao-deploy` applies that manifest before the Helm upgrade. Live DNS/deployment verification remains pending. Live progress on 2026-06-15: the operator reached the OpenBao browser UI at `https://bao.coulomb.social`, authenticated through the approved KeyCape/OIDC browser path, and wrote the Inter-Hub bootstrap operator key into the `platform/` KV engine. OpenBao audit evidence shows successful access to the expected path, so the public UI exposure is live enough for the HF-WP-0001 credential-custody workflow. --- ### T03 - Add KeyCape UI Redirect URIs ```task id: HF-WP-0002-T03 status: done priority: high target_repo: net-kingdom state_hub_task_id: "fc1d5850-eed9-4fd6-aac4-8c0e89d8b67d" ``` Update the KeyCape OpenBao admin client to include: ```text https://bao.coulomb.social/ui/vault/auth/netkingdom/oidc/callback ``` Keep the existing localhost CLI callback URIs and the earlier `https://bao.coulomb.social/ui/vault/auth/keycape/oidc/callback` compatibility callback unless there is a separate decision to retire them. Done when KeyCape accepts the OpenBao UI callback for the `openbao-admin` client and the deployed KeyCape configuration verifies cleanly. Code progress on 2026-06-15: `net-kingdom` now includes the preferred `netkingdom` browser callback URI and the `keycape` compatibility callback in both the full `create-secrets.sh` KeyCape config generator and the focused live `openbao-client-config.py` patch/verify helper. The focused verifier also probes CLI, `netkingdom`, and `keycape` redirect URIs. Live KeyCape rollout verification for the preferred mount remains pending. Live completion on 2026-06-15: patched the live `sso/keycape-config` Secret with the code-defined OpenBao admin client settings, restarted the `sso/keycape` deployment, and verified: - the `openbao-admin` client and LLDAP OU lookup settings are present; - the public KeyCape authorize endpoint accepts the CLI callback; - the public KeyCape authorize endpoint accepts the browser UI `netkingdom` mount callback; - the public KeyCape authorize endpoint accepts the browser UI `keycape` compatibility callback; - the KeyCape discovery endpoint responds through a local port-forward to the rolled-out pod. --- ### T04 - Add OpenBao UI Redirect URIs To platform-admin Role ```task id: HF-WP-0002-T04 status: done priority: high target_repo: railiance-platform state_hub_task_id: "4f69cacb-9d8f-4ab6-a84f-3c9041f0d39a" ``` Update the OpenBao `auth/netkingdom/role/platform-admin` role so `allowed_redirect_uris` includes: ```text https://bao.coulomb.social/ui/vault/auth/netkingdom/oidc/callback ``` Keep the `auth/keycape/role/platform-admin` compatibility role aligned while it remains enabled. Keep both roles bound to the intended KeyCape claims/groups and the `platform-admin` policy. Do not broaden this to root. Done when the role supports browser UI login without breaking the existing CLI OIDC path. Code progress on 2026-06-15: `net-kingdom/sso-mfa/k8s/keycape/configure-openbao-oidc.sh` now configures both `auth/netkingdom/role/platform-admin` and the `auth/keycape/role/platform-admin` compatibility role with the browser callback URIs while preserving the existing localhost CLI callbacks. Live preferred role update remains pending. Live blocker on 2026-06-15: attempted non-secret verification using the OpenBao pod token helper. The token can authenticate to OpenBao and generate audit activity, but it receives `403 permission denied` for `sys/audit`, `sys/mounts`, `sys/auth`, `sys/capabilities-self`, and `auth/netkingdom/role/platform-admin`. Updating or verifying the live `platform-admin` OIDC role therefore still needs an attended OpenBao root/sudo token handoff or a browser/UI update by the operator. No token values were printed or copied into Git, State Hub, or chat. Completed on 2026-06-19: applied the live OpenBao OIDC configuration with an approved operator token (not recorded). Enabled the missing `auth/netkingdom` OIDC mount, wrote KeyCape discovery config for both `netkingdom` and `keycape`, and aligned `auth/netkingdom/role/platform-admin` and `auth/keycape/role/platform-admin` to the code-defined redirect URI set: - CLI: `http://localhost:8250/oidc/callback`, `http://127.0.0.1:8250/oidc/callback` - Browser: `https://bao.coulomb.social/ui/vault/auth/netkingdom/oidc/callback` - Compatibility: `https://bao.coulomb.social/ui/vault/auth/keycape/oidc/callback` Live verification: - `bao read auth/netkingdom/role/platform-admin` shows all four URIs. - `bao read auth/keycape/role/platform-admin` shows the same aligned set. - Public `POST /v1/auth/netkingdom/oidc/auth_url` accepts the browser callback. - `verify-openbao-client.sh` still passes CLI, `netkingdom`, and `keycape` redirect probes. --- ### T05 - Verify Browser Login And Metadata-Only Secret Inspection ```task id: HF-WP-0002-T05 status: done priority: high state_hub_task_id: "31d1da2d-8498-4c7d-a6fa-da9d0133bfe2" ``` Perform an attended browser login: 1. Open `https://bao.coulomb.social`. 2. Choose the KeyCape/OIDC auth method mounted at `netkingdom`. 3. Use role `platform-admin`. 4. Authenticate via `kc.coulomb.social` with MFA. 5. Confirm the user can see permitted metadata paths. 6. Confirm the user cannot bypass auth or obtain root-level authority. For the `HF-WP-0001` unblock, inspect only metadata/path presence for the Inter-Hub operator key location. Do not copy secret values into Git, State Hub, chat, or workplans. Done when browser login succeeds through the approved KeyCape/OIDC browser path and the operator can determine whether an Inter-Hub operator key exists without installing a local `bao` CLI. Progress on 2026-06-15: the operator reached the OpenBao UI and completed an attended platform-admin browser login. The preferred `netkingdom` mount has been added in code and remains to be rolled out and used for the final metadata-only inspection proof. Completed on 2026-06-15: metadata-only inspection found no existing suitable Inter-Hub operator credential. The operator then minted a temporary `inter-hub-bootstrap-operator` key directly in the Inter-Hub database and stored it in OpenBao at: ```text platform/operators/inter-hub/bootstrap-operator ``` Only non-secret evidence was recorded in the workplan and State Hub: OpenBao audit shows successful create/read activity for the path, and the Inter-Hub DB shows an active static key with prefix `8fab0bef`. --- ### T06 - Update Operator Runbooks ```task id: HF-WP-0002-T06 status: done priority: medium state_hub_task_id: "f25bec03-18de-4080-b44b-d5e87e688f4e" ``` Update the relevant operator docs in HelixForge, Railiance Platform, and NetKingdom so future operators know: - `kc.coulomb.social` is the KeyCape/OIDC login authority. - `bao.coulomb.social` is the OpenBao UI. - Browser login uses auth path `netkingdom` and role `platform-admin`. - Metadata-only inspection is preferred when looking for whether a secret exists. - Secret values, OpenBao tokens, Inter-Hub keys, and one-time displayed API keys must be stored only in the approved secret path. Done when the next operator can follow the browser path without rediscovering the CLI-only limitation. Completed on 2026-06-15: updated the Railiance Platform OpenBao runbook and NetKingdom KeyCape/OpenBao docs to describe `bao.coulomb.social`, the preferred `netkingdom` KeyCape/OIDC auth path, `platform-admin` browser login, metadata-only inspection, and the no-root-token/no-secret-copying boundary. ## Implementation Log ### 2026-06-15 - Declarative browser UI exposure prepared Implemented the code and documentation needed for the approved browser UI path: - `railiance-platform/helm/openbao-values.yaml` enables chart-native Ingress for `bao.coulomb.social` with Traefik, `letsencrypt-prod`, TLS secret `bao-tls`, and active OpenBao service routing. - `railiance-platform/helm/openbao-middleware.yaml` adds Traefik HSTS and rate-limit middlewares. - `railiance-platform/Makefile` applies the OpenBao middleware before Helm deployment. - `net-kingdom/sso-mfa/k8s/keycape/create-secrets.sh` and `openbao-client-config.py` include the preferred `netkingdom` browser callback URI and the `keycape` compatibility callback for `openbao-admin`. - `net-kingdom/sso-mfa/k8s/keycape/configure-openbao-oidc.sh` writes the same browser callback URIs to the OpenBao `auth/netkingdom` and `auth/keycape` `platform-admin` roles. - `net-kingdom` verifiers now expect and probe CLI, `netkingdom`, and `keycape` callback URIs. - Railiance Platform and NetKingdom docs now describe the browser path and secret-handling boundaries. Verification performed: - `git diff --check` passed in `railiance-platform` and `net-kingdom`. - OpenBao YAML values and middleware parse successfully with Python/YAML. - Modified NetKingdom Python helper compiles with `python3 -m py_compile`. - Modified NetKingdom shell scripts pass `bash -n`. - `make -n openbao-deploy` shows middleware applied before the Helm upgrade. Verification not performed: - Helm chart rendering, because `helm` is not installed in this local shell. - Live KeyCape config rollout. - Live OpenBao role update. - Live rollout verification for the preferred `netkingdom` auth mount. ### 2026-06-15 - Preferred netkingdom auth mount added After the first successful browser login, the preferred OpenBao OIDC auth mount was changed from `keycape` to `netkingdom` to match the platform domain language and reduce operator confusion in the UI. The `keycape` mount remains configured as a compatibility alias. ### 2026-06-19 - Live netkingdom OIDC mount and role alignment Applied the pending T04 live configuration: - Enabled `auth/netkingdom` OIDC and wrote KeyCape discovery config. - Updated `auth/netkingdom/role/platform-admin` and `auth/keycape/role/platform-admin` with the browser and CLI redirect URI set defined in `configure-openbao-oidc.sh`. - Verified the public `netkingdom` OIDC `auth_url` endpoint accepts the browser callback and `verify-openbao-client.sh` still passes. No OpenBao tokens, secret values, or Inter-Hub keys were copied into Git, State Hub, chat, or workplan text. ## Acceptance Criteria This workplan is complete when: 1. `https://bao.coulomb.social` serves the OpenBao UI over valid HTTPS. 2. Browser login through KeyCape works for the approved platform operator. 3. The `platform-admin` OpenBao policy is used for normal UI access. 4. The OpenBao UI callback URI is registered in both KeyCape and OpenBao. 5. Audit evidence shows authenticated UI access. 6. Operators can inspect OpenBao secret metadata without a local `bao` CLI. 7. The `HF-WP-0001` Inter-Hub operator-key discovery/storage path is no longer blocked on local CLI setup. ## Notes OpenBao UI exposure is a convenience improvement, but it is also a privileged control-plane exposure. Treat this as an attended platform/security change, not as a plain frontend routing task.