KEY-WP-0004-T01: adopt tenant:<grouping>:<name> identifier, binky -> friendly
Bernd's decision: role words (customer/vendor) collide with the separate capability-role dimension a tenant can hold (PLTF/IAM/VEN/CUS, per net-kingdom/docs/princedom-isolation-exploration.md's unratified model -- Binky itself is both CUS and, later, VEN). Tenants are grouped instead by onboarding-risk/entity-shape, orthogonal to role: trial, friendly, single, small, medium, large, enterprise, consumer, family, community, association, agentic. Binky maps to friendly -> tenant:friendly:binky, replacing the earlier tenant:customer:binky throughout this workplan. Two open questions flagged, not resolved here: where tenant:coulomb (the platform's own internal/reference tenant) fits this external-shaped grouping list, and whether net-kingdom should ratify this list into iam-profile_v0.2.md's Tenant Claim section, since it currently still documents the old customer/sandbox suggested identifiers and NetKingdom owns that canon per ADR-0011. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
parent
7ddc48d3cd
commit
df26aee844
1 changed files with 54 additions and 20 deletions
|
|
@ -49,28 +49,62 @@ priority: high
|
|||
state_hub_task_id: "ec65d1be-11cb-421f-84dd-f401206526fe"
|
||||
```
|
||||
|
||||
The IAM profile's tenant identifiers (`tenant:platform`, `tenant:coulomb`,
|
||||
`tenant:sandbox:<name>`, `tenant:customer:<name>`) are documented as
|
||||
*suggested*, not exhaustive — but `tenant:customer:<name>` is the closest fit
|
||||
for the first real operating/customer-plane tenant, distinct from the
|
||||
`tenant:coulomb` ecosystem-development plane.
|
||||
**Decided 2026-07-23 (Bernd):** the IAM profile's `tenant:customer:<name>` /
|
||||
`tenant:sandbox:<name>` suggested identifiers name a tenant by **capability
|
||||
role** (customer, vendor, ...) — but tenants already known to hold multiple
|
||||
roles at once (see `net-kingdom/docs/princedom-isolation-exploration.md`'s
|
||||
unratified `PLTF`/`IAM`/`VEN`/`CUS` role model; Binky itself is both `CUS`
|
||||
and, later, `VEN`). Using a role word as the tenant *grouping* would collide
|
||||
with that separate role dimension. Decision: classify tenants by an
|
||||
onboarding-risk / entity-shape **grouping**, orthogonal to capability role:
|
||||
|
||||
**Recommended default, to confirm before implementing:** `tenant:customer:binky`
|
||||
— matching the slug already live in production OpenBao paths
|
||||
(`tenants/binky/qonto-api`, used by `qonto-assistant` today) rather than
|
||||
`tenant:customer:binky-hedgehog`, to avoid a slug mismatch between the new
|
||||
IAM tenant claim and the existing secret-custody path convention. Flag to
|
||||
Bernd for explicit confirmation before provisioning — tenant identifiers are
|
||||
expensive to rename once tokens and downstream config reference them.
|
||||
```text
|
||||
trial — test/trial/showcase tenants only
|
||||
friendly — known, easily reached, tolerant of experimentation/instability
|
||||
single — one-person business entities (freelance consultants)
|
||||
small — up to 10 employees at time of onboarding (attoo)
|
||||
medium — up to 100 employees (attoo)
|
||||
large — up to 1000 employees (attoo)
|
||||
enterprise — 1001+ employees (attoo)
|
||||
consumer — private individuals
|
||||
family — a legal family
|
||||
community — a non-legal group of people
|
||||
association — a legal association of people
|
||||
agentic — financially enabled AI entities
|
||||
```
|
||||
|
||||
`tenant:<grouping>:<name>` replaces `tenant:customer:<name>` /
|
||||
`tenant:sandbox:<name>` as the identifier shape. **Binky maps to `friendly`**
|
||||
— known, reachable, tolerant of early instability — giving
|
||||
**`tenant:friendly:binky`** (slug matches the OpenBao path already in
|
||||
production, `tenants/binky/qonto-api`).
|
||||
|
||||
**Open question, not yet resolved by this decision:** this grouping list
|
||||
classifies tenants as external-shaped entities: it has no obvious slot for
|
||||
`tenant:coulomb` itself (the platform's own internal/reference tenant,
|
||||
ADR-0006) — none of `trial`/`friendly`/`single`/.../`agentic` fit "the
|
||||
platform building itself." Confirm with Bernd whether `tenant:coulomb` stays
|
||||
an ungrouped special case (alongside `tenant:platform`) or gets folded into
|
||||
this scheme somehow, before treating the grouping list as complete.
|
||||
|
||||
**Also open:** this is a fleet-wide vocabulary decision — the ratified
|
||||
`net-kingdom/canon/standards/iam-profile_v0.2.md` "Tenant Claim" section
|
||||
still documents the old `customer`/`sandbox` suggested identifiers, and
|
||||
NetKingdom owns that canon per ADR-0011. Recording this grouping list only
|
||||
in this key-cape workplan lets it drift from canon. Recommend a follow-up:
|
||||
either a decision record or an ADR in `net-kingdom` adopting this grouping
|
||||
list as the tenant-identifier standard, superseding the old suggested
|
||||
identifiers. Not drafted here — flagging so it isn't lost.
|
||||
|
||||
Provision whatever tenant/org-unit boundary key-cape's current backend
|
||||
(LLDAP/Authelia) needs so tokens issued for subjects under this tenant
|
||||
correctly carry `tenant:customer:binky` and nothing implies platform-root
|
||||
correctly carry `tenant:friendly:binky` and nothing implies platform-root
|
||||
authority for it (profile rule: tenant administration for a tenant must
|
||||
never imply platform-root authority).
|
||||
|
||||
Done when: tenant identifier confirmed and recorded (decision record or
|
||||
canon note); a test-subject token carries the correct `tenant` claim.
|
||||
Done when: `tenant:coulomb`'s place in the grouping scheme is resolved; the
|
||||
`net-kingdom` canon-update question above is answered (drafted or explicitly
|
||||
deferred); a test-subject token carries the `tenant:friendly:binky` claim.
|
||||
|
||||
## Task: Provision bernd.worsch@binky-hedgehog.com as tenant-admin
|
||||
|
||||
|
|
@ -83,7 +117,7 @@ state_hub_task_id: "b5cb4497-095c-4dd7-af31-831deddd422e"
|
|||
|
||||
Create the user in key-cape's current backend, enroll MFA per profile
|
||||
requirements (`assurance` claim, `net-kingdom/canon/standards/iam-profile_v0.2.md`),
|
||||
and assign a tenant-admin role/group scoped to `tenant:customer:binky` only.
|
||||
and assign a tenant-admin role/group scoped to `tenant:friendly:binky` only.
|
||||
|
||||
**Prerequisite outside this repo's control:** the `binky-hedgehog.com` mailbox
|
||||
for `bernd.worsch@` must exist and be reachable for account verification and
|
||||
|
|
@ -91,7 +125,7 @@ MFA enrollment. Flag to Bernd before starting — this task cannot complete
|
|||
without it.
|
||||
|
||||
Done when: `bernd.worsch@binky-hedgehog.com` completes OIDC/PKCE + MFA login
|
||||
and receives a token carrying `tenant:customer:binky` and a tenant-admin role
|
||||
and receives a token carrying `tenant:friendly:binky` and a tenant-admin role
|
||||
claim; the same token does **not** grant access to `tenant:platform` or any
|
||||
other tenant.
|
||||
|
||||
|
|
@ -106,7 +140,7 @@ state_hub_task_id: "fbe9d2e0-7532-4403-8e12-947aa8fd0da7"
|
|||
|
||||
Register an OIDC client per the profile's service-account/workload-identity
|
||||
flow (`client_credentials` or the documented workload-token-exchange
|
||||
equivalent — §"Service Account Flow"), scoped to `tenant:customer:binky`,
|
||||
equivalent — §"Service Account Flow"), scoped to `tenant:friendly:binky`,
|
||||
with the minimum role/scope `qonto-assistant`'s MCP and REST surfaces
|
||||
actually need. No interactive login for this client — it's for agent-harness
|
||||
sessions and other automated callers, not humans.
|
||||
|
|
@ -117,7 +151,7 @@ through T04's secrets-engine/OpenBao lane.
|
|||
|
||||
Done when: a `client_credentials` token exchange against key-cape succeeds
|
||||
for this client and produces a short-lived service token carrying
|
||||
`tenant:customer:binky`; the `client_id` and granted scopes are documented
|
||||
`tenant:friendly:binky`; the `client_id` and granted scopes are documented
|
||||
here; no secret material appears anywhere in this repo's history.
|
||||
|
||||
## Task: Route client_secret custody through secrets-engine + OpenBao
|
||||
|
|
@ -206,7 +240,7 @@ state_hub_task_id: "9511a7ef-0a04-45db-8a7b-598ab77ce737"
|
|||
Mark workplan finished when T01–T05 are done (T06 may legitimately remain
|
||||
`todo`/parked by design — see its own task note). Confirm end to end: a
|
||||
human token (bernd.worsch@binky-hedgehog.com, tenant-admin) and a service
|
||||
token (qonto-assistant workload client) both resolve to `tenant:customer:binky`
|
||||
token (qonto-assistant workload client) both resolve to `tenant:friendly:binky`
|
||||
and nothing else; the credential lane is discoverable via `warden access`
|
||||
without Bernd touching key-cape/OpenBao admin surfaces directly. Note the
|
||||
`qonto-assistant`-side follow-up workplan (swap bearer token for
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue