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	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/keycape/oidc/callback
  

• UI access maps to the existing platform-admin policy through the KeyCape OIDC path.

• 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/keycape/role/platform-admin allowed_redirect_uris.

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 URI

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/keycape/oidc/callback

Keep the existing localhost CLI callback URIs unless there is a separate decision to retire CLI login.

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 browser callback URI 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 both CLI and browser redirect URIs. Live KeyCape rollout verification remains pending.

---

T04 - Add OpenBao UI Redirect URI 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/keycape/role/platform-admin role so allowed_redirect_uris includes:

https://bao.coulomb.social/ui/vault/auth/keycape/oidc/callback

Keep the role 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 writes the browser callback URI into the OpenBao auth/keycape/role/platform-admin allowed_redirect_uris while preserving the existing localhost CLI callbacks. Live role update and browser proof remain pending.

---

T05 - Verify Browser Login And Metadata-Only Secret Inspection

id: HF-WP-0002-T05
status: wait
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 keycape.
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 and the operator can determine whether an Inter-Hub operator key exists without installing a local bao CLI.

Waiting on live DNS/deployment, KeyCape config rollout, OpenBao role update, and an attended platform-admin browser login.

---

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 keycape 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 KeyCape OIDC callback, 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 browser callback URI for openbao-admin.
• net-kingdom/sso-mfa/k8s/keycape/configure-openbao-oidc.sh writes the same browser callback URI to the OpenBao platform-admin role.
• net-kingdom verifiers now expect and probe the browser callback URI.
• 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.

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.