From 7d96ee4a43b802c4031639c79a626e5e35929463 Mon Sep 17 00:00:00 2001 From: tegwick Date: Tue, 6 Oct 2026 14:05:37 +0200 Subject: [PATCH] Confirm groups and MFA for the secrets-engine-openbao operator reader Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 132360@bnt-lap001 Assistant-Session: 769b1afd-4330-4c86-96b2-e510e26db42b --- docs/secrets-engine-openbao-owner-packet.md | 28 ++++++++++++++++++--- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/docs/secrets-engine-openbao-owner-packet.md b/docs/secrets-engine-openbao-owner-packet.md index 8aa5bc5..2b7e30e 100644 --- a/docs/secrets-engine-openbao-owner-packet.md +++ b/docs/secrets-engine-openbao-owner-packet.md @@ -35,10 +35,12 @@ These are proposals, not existing allocated/provisioned resources: to that single path, 15-minute reader tokens and explicit safe target metadata. - Only one new Deployment env reference: KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET from that Secret/key. Do not copy values into deployment YAML or config. -- Client-side consumer: an explicitly chosen mode-0600 file outside every Git - worktree, accepted by secrets-engine's service-auth provider. Its actual host, - owner, path, delivery mechanism and lifecycle must be named by secrets-engine - and platform before approval; no directory or secret value is guessed here. +- Client-side consumer (superseded 2026-10-06 by founder direction and the + ops-mason plan `plans/keycape-secrets-engine-openbao-client-custody.md`, + MASON-WP-0009): there is no persistent workstation copy. The value lives only + in OpenBao. secrets-engine reads it per command into memory through the attended + OIDC role `keycape-secrets-engine-openbao-operator-workload-kv-read` on + `auth/netkingdom`, then revokes that token. Platform must allocate/review separate custody CCR and issuer-reader metadata. The consumer file delivery cannot be treated as implied by issuer-side ESO. @@ -46,6 +48,24 @@ A single random confidential value serves the issuer and the consumer in their separate approved copies; approval/verifier/requester credentials stay separate. No existing live version, receipt, protected copy or registration is asserted. +## KeyCape confirmation for the operator OIDC reader (2026-10-06) + +The reader logs in through the `openbao-admin` public client (authorization +code, scopes include `groups`). Source behaviour at e22029e: + +- Groups: human ID tokens always carry `groups` from LLDAP + (`src/internal/server/oidc/token.go`, `claims["groups"]`), so + `groups_claim: groups` with bound `net-kingdom-admins` is satisfiable. This + matches CCR-2026-0019. +- MFA: `openbao-admin` has no `mfaRequired` pin. MFA is enforced because the + deployed provider default is `privacyidea.requireForAll: true` (NetKingdom + README). That is a deployment default rather than a client pin, so the role + should bind the assurance claim as well: `bound_claims_type: string`, + `"/assurance/level": "aal2"`. The token carries `assurance` as + `{level, methods, mfa, at}`, and `aal2` appears only after a verified factor. + Pinning `mfaRequired: true` on `openbao-admin` is the stronger NetKingdom + option, but it changes every OpenBao admin login and needs its own go. + ## Concrete preparation still required 1. Platform and secrets-engine accept/correct the proposed exact custody