Cordy/Cairn

Fork 0

OpenBao key-custody backend (uniform AD + Keycloak) #29

New issue

Closed

opened 2026-07-25 17:43:56 +00:00 by Cordy · 2 comments

Cordy commented

2026-07-25 17:43:56 +00:00

Owner

Manuel's suggestion for the open AD key-management question. Add a third KeyProvider backing per-user age keys in OpenBao (the active Linux-Foundation Vault fork; its transit engine is "encryption/keys as a service" — per-key derivation, convergent encryption, rotation, audit logs).

Gives uniform key custody across both Keycloak and AD users (AD has no writable profile attributes — the current gap).
Answers the custody-storage question (where keys live), not the access question (the backend still fetches/holds the key at runtime).
New dependency/service — weigh against the tiny-trust-surface goal (§1.4).

Source: https://openbao.org/docs/secrets/transit/

Manuel's suggestion for the open AD key-management question. Add a third `KeyProvider` backing per-user age keys in **OpenBao** (the active Linux-Foundation Vault fork; its **transit engine** is "encryption/keys as a service" — per-key derivation, convergent encryption, rotation, audit logs). - Gives **uniform** key custody across both Keycloak *and* AD users (AD has no writable profile attributes — the current gap). - Answers the *custody-storage* question (where keys live), **not** the *access* question (the backend still fetches/holds the key at runtime). - New dependency/service — weigh against the tiny-trust-surface goal (§1.4). Source: https://openbao.org/docs/secrets/transit/

Cordy added this to the v0.4 — Real competitor (parity + hardening) milestone

2026-07-25 17:43:56 +00:00

Cordy referenced this issue

2026-08-03 19:02:24 +00:00

Credential-derived key custody — spike (local/LDAP only) #30

Cordy commented

2026-08-03 19:03:03 +00:00

Author

Owner

Decision — approved (Manuel's review, relayed by Nikola 2026-07-31):

"Yes, to be used as a key-custody backend."

Un-gated. OpenBao becomes the approved key-custody backend alongside (eventually uniform across) AD + Keycloak environments. Implementation prerequisites when greenlit: deploy OpenBao on k3s (GitOps like everything else), define the custody interface as a third keyCustody mode next to keycloak-profile and deployment, and per #30's rejection the model stays unique-key-per-user/group — OpenBao stores and serves those identities, it does not derive them.

**Decision — approved (Manuel's review, relayed by Nikola 2026-07-31):** > "Yes, to be used as a key-custody backend." **Un-gated.** OpenBao becomes the approved key-custody backend alongside (eventually uniform across) AD + Keycloak environments. Implementation prerequisites when greenlit: deploy OpenBao on k3s (GitOps like everything else), define the custody interface as a third `keyCustody` mode next to `keycloak-profile` and `deployment`, and per #30's rejection the model stays unique-key-per-user/group — OpenBao stores and serves those identities, it does not derive them.

Cordy referenced this issue from a commit

2026-08-04 10:23:03 +00:00

ci: inspect auth middleware + key custody wiring (#96 #29 #31)

Cordy referenced this issue from a commit

2026-08-04 10:30:32 +00:00

feat(encrypt): OpenBao KV key-custody backend (#29)

Cordy referenced this issue from a commit

2026-08-04 10:31:18 +00:00

test(encrypt): fake OpenBao KV v2 coverage (#29)

Cordy referenced this issue from a commit

2026-08-04 10:35:48 +00:00

fix(test): rename ctx helper to avoid clash with group_test (#29)

forgejo-actions referenced this issue from a commit

2026-08-04 10:38:48 +00:00

feat: live group resolution (#96), OpenBao custody (#29), domain separation (#31)

Cordy referenced this issue

2026-08-04 10:40:41 +00:00

Live group resolution (#96), OpenBao custody (#29), domain separation (#31) #99

Cordy referenced this issue from a commit

2026-08-04 10:42:51 +00:00

Merge pull request 'Live group resolution (#96), OpenBao custody (#29), domain separation (#31)' (#99) from feat/custody-live-groups into main

forgejo-actions referenced this issue from a commit

2026-08-04 10:44:02 +00:00

docs: changelog for v0.3.28 (#96 #29 #31)

Cordy commented

2026-08-04 10:48:02 +00:00

Author

Owner

Shipped in v0.3.28 (PR #99) as keyCustody: "openbao".

Implemented as a KV v2 custody store, not the transit engine Manuel linked — deliberate: Cairn's at-rest format stays plain age files so age -d recovery keeps working (sovereignty feature), which means the backend must hand cairnd the identity rather than perform the crypto. Layout: {mount}/data/{prefix}/users/<username> and .../groups/<space> (#18 group keys covered), field identity. Lazy provisioning with check-and-set (cas=0) so racing replicas can never overwrite a live custody key. Config: openbaoBaseUrl, openbaoToken (or CAIRN_ENC_OPENBAO_TOKEN), openbaoMount (default secret), openbaoPathPrefix (default cairn). Recovery recipient handled identically to the other custody modes.

Unit-tested against a fake KV v2 (provision, group isolation, cas race, recovery). Not yet e2e'd against a real OpenBao — that wants an OpenBao instance on k3s, same pattern as the Keycloak e2e; worth doing before any customer runs this custody mode. Closing the build; the e2e can ride the AD-parity dress rehearsal.

Shipped in **v0.3.28** (PR #99) as `keyCustody: "openbao"`. Implemented as a **KV v2** custody store, not the transit engine Manuel linked — deliberate: Cairn's at-rest format stays plain age files so `age -d` recovery keeps working (sovereignty feature), which means the backend must hand cairnd the identity rather than perform the crypto. Layout: `{mount}/data/{prefix}/users/<username>` and `.../groups/<space>` (#18 group keys covered), field `identity`. Lazy provisioning with check-and-set (`cas=0`) so racing replicas can never overwrite a live custody key. Config: `openbaoBaseUrl`, `openbaoToken` (or `CAIRN_ENC_OPENBAO_TOKEN`), `openbaoMount` (default `secret`), `openbaoPathPrefix` (default `cairn`). Recovery recipient handled identically to the other custody modes. Unit-tested against a fake KV v2 (provision, group isolation, cas race, recovery). **Not yet e2e'd against a real OpenBao** — that wants an OpenBao instance on k3s, same pattern as the Keycloak e2e; worth doing before any customer runs this custody mode. Closing the build; the e2e can ride the AD-parity dress rehearsal.

Cordy closed this issue

2026-08-04 10:48:08 +00:00

Cordy referenced this issue

2026-08-04 17:23:30 +00:00

OpenBao custody: live e2e against a real OpenBao instance #112