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

---
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.