chore(consistency): renormalize lifecycle state [auto]

Updated by fix-consistency on 2026-06-15:
  - workplan status: ready → active
This commit is contained in:
2026-06-15 01:00:05 +02:00
parent dc63bbdc84
commit 4a5077dec0

View File

@@ -0,0 +1,353 @@
---
id: HF-WP-0002
type: workplan
title: "Expose OpenBao Browser UI at bao.coulomb.social"
domain: helix_forge
repo: helix-forge
status: active
owner: codex
topic_slug: openbao-browser-ui
created: "2026-06-15"
updated: "2026-06-15"
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/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:
```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: progress
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.
---
### T03 - Add KeyCape UI Redirect URI
```task
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:
```text
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
```task
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:
```text
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
```task
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
```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 `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.