Files
helix-forge/workplans/HF-WP-0002-openbao-browser-ui-at-bao-coulomb-social.md
tegwick 071b4f2bbe chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-15:
  - HF-WP-0002-T05: wait → progress
2026-06-15 02:03:24 +02:00

13 KiB

id, type, title, domain, repo, status, owner, topic_slug, created, updated, planning_priority, planning_order, related_repos, related_workplans, state_hub_workstream_id
id type title domain repo status owner topic_slug created updated planning_priority planning_order related_repos related_workplans state_hub_workstream_id
HF-WP-0002 workplan Expose OpenBao Browser UI at bao.coulomb.social helix_forge helix-forge active codex openbao-browser-ui 2026-06-15 2026-06-15 high 2
railiance-platform
net-kingdom
key-cape
inter-hub
ops-hub
HF-WP-0001
c1b5f54d-2f26-453d-966c-6353df0b6aec

Expose OpenBao Browser UI at bao.coulomb.social

Goal

Make OpenBao usable through a browser at:

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:

    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:

    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

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

id: HF-WP-0002-T02
status: progress
priority: high
target_repo: railiance-platform
state_hub_task_id: "41e52213-0a1e-417c-a4d0-5db5141b600d"

Implement DNS, TLS, and ingress for:

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.


T03 - Add KeyCape UI Redirect URIs

id: HF-WP-0002-T03
status: progress
priority: high
target_repo: net-kingdom
state_hub_task_id: "fc1d5850-eed9-4fd6-aac4-8c0e89d8b67d"

Update the KeyCape OpenBao admin client to include:

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.


T04 - Add OpenBao UI Redirect URIs To platform-admin Role

id: HF-WP-0002-T04
status: progress
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:

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.


T05 - Verify Browser Login And Metadata-Only Secret Inspection

id: HF-WP-0002-T05
status: progress
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 preferred netkingdom mount 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.


T06 - Update Operator Runbooks

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 DNS/TLS/Ingress rollout.
  • Live KeyCape config rollout.
  • Live OpenBao role update.
  • Attended browser login and metadata-only secret-path inspection.

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.

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.