helix-forge/workplans/HF-WP-0002-openbao-browser-ui-at-bao-coulomb-social.md

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	finished	codex	openbao-browser-ui	2026-06-15	2026-06-19	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: done
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.

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

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:

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

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:

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

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:

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

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.