kayg/infraternal

Watch

Fork 0

Secrets: an intuitive interface over OpenBao #287

New issue

Open

opened 2026-11-01 10:16:25 +00:00 by kayg · 1 comment

kayg commented

2026-11-01 10:16:25 +00:00

Owner

Owner (kayg, 2026-11-01): "I had this exact idea that we should do secrets as in provide a super intuitive interface for openbao." Product idea: infraternal provides a friendly UI/CLI for secrets backed by OpenBao (store, scope to machines/services, rotate, audit), and infraternal's own secrets (DNS-01 provider tokens #281, CA admin material, API keys) move onto it through one custody interface. Related: #262 §6 (OpenBao deployment), #269 inventory, #281 P6. Needs a research/plan round before code.

kayg referenced this issue

2026-11-01 11:11:36 +00:00

Secrets: node-sealed custody for DNS-01 tokens (replaces J62's owner-only file) #289

kayg referenced this issue

2026-11-01 11:12:51 +00:00

Reverse proxy: Traefik on demand — implementation plan #281

kayg referenced this issue

2026-11-01 11:13:08 +00:00

Reverse proxy: Traefik on demand — implementation plan #281

kayg referenced this issue

2026-11-01 11:19:06 +00:00

Reverse proxy: Traefik on demand — implementation plan #281

kayg referenced this issue

2026-11-01 14:42:58 +00:00

Reverse proxy: Traefik on demand — implementation plan #281

kayg commented

2026-11-02 01:17:08 +00:00

Author

Owner

P5 research and proposed slices. recommendation: put a simple secrets interface over kayg’s existing OpenBao. OpenBao remains the store; infraternal supplies workflows and access checks. #289’s backend choice is settled.

What we build

Connect using an HTTPS address, trusted CA, auth method/mount and allowed KV-v2 mount/prefix. Show connection status, folders, search, masked values and explicit reveal; then editing, versions, restore and sharing. A secret can be assigned to machines/services or people through infraternal’s existing access rules. Separate “use for this service” from “reveal/edit”; authorize every UI/CLI/MCP action and filter listings too. OpenBao policies bound integration access; infraternal further restricts each caller. People management respects D31/D33’s commercial seam and timing.

Internal consumers use secret references: DNS tokens through #289’s DnsTokenCustody, then Apple signing certificates/private keys and future node secrets. Only the designated infraternal agent receives the required value. R2 on #261 means DNS credentials reach the proxy through supported *_FILE paths, never config values or inherited token env vars. Signing material needs a separate keychain lifecycle review. D8 permits server plaintext access; this does not change D23’s SSH-key rules or D244’s locked, dump-excluded CA-key memory requirement.

Auth: proposed starting point, not a new owner decision

AppRole first: works with passkeys and unattended renewal. Separate browse and DNS-consumer policies; no root token or cluster-wide policy-admin rights. Bootstrap through a protected credential file/FD, optionally response-wrapped delivery; keep short-lived renewable client tokens in memory. Wrapping is delivery protection, not restart persistence: expired SecretIDs need reprovisioning. OpenBao sees a service identity; infraternal records the person/node and request IDs. AppRole docs.
Server-issued JWT later: OpenBao validates our signing key/JWKS, issuer, audience, subject and bound claims, issuing scoped tokens. Better person/node attribution without SecretIDs, but adds signing-key rotation and claim/policy mapping. JWT auth needs no full OIDC provider; interactive OIDC is separate. JWT API.
Per-person OpenBao tokens: reuse individual policies and attribution, but add login/expiry/revocation handling; unattended consumers still need service auth. Tokens stay server-side.

No credentials in argv, logs, URLs or browser storage. Browser reveal/edit values exist only transiently in memory; exclude payloads from telemetry, caches and error messages. Verify TLS and bound timeouts.

Thin slices, ordered by value and effort

Smallest useful slice, medium effort: one existing connection, owner-only read-only KV-v2 browse/reveal under an allowed prefix, plus the narrowly scoped DNS-token write/read adapter for #289. Preserve its private file handoff and test restart, denied access and OpenBao outage. Record metadata-only activity from day one.
Everyday management, medium: create/edit with version-conflict protection, history/restore and explicit machine/service assignments. KV-v2 lists via /v1/<mount>/metadata/<path> and reads/writes via /data/<path>; CAS prevents lost edits. KV-v2 API.
Sharing and audit, larger: wire people permissions when multi-user work is authorized; add an activity view showing who used/changed which reference and the outcome. Full OpenBao history needs an audit sink: /sys/audit manages devices, not historical events. Preserve OpenBao’s sensitive-field hashing. Audit docs.
Rotation and more consumers, larger: start with guided replacement, verify consumer adoption, then revoke the old provider credential. Saving a KV version does not rotate a DNS token or signing certificate. Automate per provider/engine later; add other consumers individually.

Owner grill: recommendation first

AppRole initially: can we provision the dedicated roles, or must the first connector use an auth method already configured on your OpenBao?
Write only an infraternal-owned prefix; browse other prefixes only when explicitly allowed: or should the editor manage existing secrets throughout selected mounts?
Keep #289’s protected last-known-good DNS file across restart/outage, replacing it only after validation: or prohibit persistent local copies and require OpenBao availability for renewal? OpenBao remains authoritative either way.
Grant service-use separately from reveal: should someone allowed to configure a machine’s DNS renewal also be allowed to see its token?

Licence: OpenBao is MPL-2.0. Calling an independently running OpenBao over HTTP is compatible with our AGPL-3.0-only client: we are not copying or linking its implementation. MPL’s file-level obligations apply if its code is incorporated/distributed. Mozilla FAQ, Q11.

Research plan: read issues/decisions, check official API/licence docs, propose slices/questions; 15-minute timebox. Read-only checkout main, base/head 5a0ec9ee7d278ddd2ed8a16bffd1ba6ad2f904c5; D244 read from origin/dev at ffebd0561a010690583481abc4d583ecaca4542e. No repository edits, builds, benchmarks, push or deployment. no code changed, gate not applicable. Findings are source research, not tested integration or measured performance.

**P5 research and proposed slices.** recommendation: put a simple secrets interface over kayg’s existing OpenBao. OpenBao remains the store; infraternal supplies workflows and access checks. #289’s backend choice is settled. **What we build** Connect using an HTTPS address, trusted CA, auth method/mount and allowed KV-v2 mount/prefix. Show connection status, folders, search, masked values and explicit reveal; then editing, versions, restore and sharing. A secret can be assigned to machines/services or people through infraternal’s existing access rules. Separate “use for this service” from “reveal/edit”; authorize every UI/CLI/MCP action and filter listings too. OpenBao policies bound integration access; infraternal further restricts each caller. People management respects D31/D33’s commercial seam and timing. Internal consumers use secret references: DNS tokens through #289’s `DnsTokenCustody`, then Apple signing certificates/private keys and future node secrets. Only the designated infraternal agent receives the required value. R2 on #261 means DNS credentials reach the proxy through supported `*_FILE` paths, never config values or inherited token env vars. Signing material needs a separate keychain lifecycle review. D8 permits server plaintext access; this does not change D23’s SSH-key rules or D244’s locked, dump-excluded CA-key memory requirement. **Auth: proposed starting point, not a new owner decision** - **AppRole first:** works with passkeys and unattended renewal. Separate browse and DNS-consumer policies; no root token or cluster-wide policy-admin rights. Bootstrap through a protected credential file/FD, optionally response-wrapped delivery; keep short-lived renewable client tokens in memory. Wrapping is delivery protection, not restart persistence: expired SecretIDs need reprovisioning. OpenBao sees a service identity; infraternal records the person/node and request IDs. [AppRole docs](https://openbao.org/docs/auth/approle/). - **Server-issued JWT later:** OpenBao validates our signing key/JWKS, issuer, audience, subject and bound claims, issuing scoped tokens. Better person/node attribution without SecretIDs, but adds signing-key rotation and claim/policy mapping. JWT auth needs no full OIDC provider; interactive OIDC is separate. [JWT API](https://openbao.org/docs/api/auth/jwt/). - **Per-person OpenBao tokens:** reuse individual policies and attribution, but add login/expiry/revocation handling; unattended consumers still need service auth. Tokens stay server-side. No credentials in argv, logs, URLs or browser storage. Browser reveal/edit values exist only transiently in memory; exclude payloads from telemetry, caches and error messages. Verify TLS and bound timeouts. **Thin slices, ordered by value and effort** 1. **Smallest useful slice, medium effort:** one existing connection, owner-only read-only KV-v2 browse/reveal under an allowed prefix, plus the narrowly scoped DNS-token write/read adapter for #289. Preserve its private file handoff and test restart, denied access and OpenBao outage. Record metadata-only activity from day one. 2. **Everyday management, medium:** create/edit with version-conflict protection, history/restore and explicit machine/service assignments. KV-v2 lists via `/v1/<mount>/metadata/<path>` and reads/writes via `/data/<path>`; CAS prevents lost edits. [KV-v2 API](https://openbao.org/docs/api/secret/kv/kv-v2/). 3. **Sharing and audit, larger:** wire people permissions when multi-user work is authorized; add an activity view showing who used/changed which reference and the outcome. Full OpenBao history needs an audit sink: [`/sys/audit`](https://openbao.org/docs/api/system/audit/) manages devices, not historical events. Preserve OpenBao’s sensitive-field hashing. [Audit docs](https://openbao.org/docs/audit/). 4. **Rotation and more consumers, larger:** start with guided replacement, verify consumer adoption, then revoke the old provider credential. Saving a KV version does not rotate a DNS token or signing certificate. Automate per provider/engine later; add other consumers individually. **Owner grill: recommendation first** 1. **AppRole initially:** can we provision the dedicated roles, or must the first connector use an auth method already configured on your OpenBao? 2. **Write only an infraternal-owned prefix; browse other prefixes only when explicitly allowed:** or should the editor manage existing secrets throughout selected mounts? 3. **Keep #289’s protected last-known-good DNS file across restart/outage, replacing it only after validation:** or prohibit persistent local copies and require OpenBao availability for renewal? OpenBao remains authoritative either way. 4. **Grant service-use separately from reveal:** should someone allowed to configure a machine’s DNS renewal also be allowed to see its token? **Licence:** OpenBao is [MPL-2.0](https://github.com/openbao/openbao/blob/main/LICENSE). Calling an independently running OpenBao over HTTP is compatible with our AGPL-3.0-only client: we are not copying or linking its implementation. MPL’s file-level obligations apply if its code is incorporated/distributed. [Mozilla FAQ, Q11](https://www.mozilla.org/en-US/MPL/2.0/FAQ/#q11-how-viral-is-the-mpl-if-i-use-mpl-licensed-code-in-my-proprietary-application-will-i-have-to-give-all-the-source-code-away). Research plan: read issues/decisions, check official API/licence docs, propose slices/questions; 15-minute timebox. Read-only checkout `main`, base/head `5a0ec9ee7d278ddd2ed8a16bffd1ba6ad2f904c5`; D244 read from `origin/dev` at `ffebd0561a010690583481abc4d583ecaca4542e`. No repository edits, builds, benchmarks, push or deployment. **no code changed, gate not applicable**. Findings are source research, not tested integration or measured performance.

No labels

launch-qa

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

kayg/infraternal#287

No description provided.

Rows
Columns