Correct platform infrastructure client tenant bindings

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e324-abce-7e51-bb2b-496f097afdb0
This commit is contained in:
tegwick 2026-09-27 16:43:31 +02:00
parent 3b0446e0ef
commit 717a97408a
7 changed files with 47 additions and 16 deletions

View file

@ -84,3 +84,22 @@ break-glass providers and require their own authorization and evidence.
Verification must inspect metadata and capabilities without reading a secret
value. A coding-agent check must prove the `agent-high-risk-boundary` deny wins
against any otherwise readable workload policy.
## Consumer/platform reconciliation — 2026-09-27
The operator clarified that platform infrastructure belongs to tenant zero,
**`tenant:platform`**, including OpenBao and its platform service identities.
Coulomb is a workload on the platform; `coulomb.social` is currently shared DNS,
not a tenant assignment. The former matching `tenant:coulomb` declarations were
wrong. `codex-railiance-platform` and `secrets-engine-openbao` now declare
`tenant:platform`, coordinated with the platform role and consumer preflight.
This source correction does not migrate live registrations or existing tokens.
Public discovery at `https://kc.coulomb.social/.well-known/openid-configuration`
was rechecked: issuer `https://kc.coulomb.social`, JWKS `/jwks`, token endpoint
`/token`, with `client_credentials` advertised. This establishes public endpoint
metadata only, not that this confidential client is registered or provisioned.
Platform's RPF-WP-0035-T02 now carries the exact proposed login-only role/config/
policy. The remaining joint acceptance is protected client custody and actual
registration, attended role provisioning, native signature/claim refusals and
OpenBao self-revocation. KEY-WP-0009's provider-contract completion is unchanged.

View file

@ -18,8 +18,8 @@ never influenced by request parameters.
| Principal | Source of `tenant` | Value in the reviewed registrations |
| --- | --- | --- |
| Service (`client_credentials`) | The client's `tenant` field. Required by config validation — a `client_credentials` client without `serviceSubject` and `tenant` fails startup validation. | In `config/service-clients.example.yaml`: `tenant:platform` for `secrets-engine-approval` and `approval-engine-operator`; `tenant:coulomb` for `codex-railiance-platform` and `secrets-engine-openbao`. |
| Human (`authorization_code`) | The directory user's tenant, falling back to the platform default when unset. | Directory value, else `tenant:coulomb`. |
| Service (`client_credentials`) | The client's `tenant` field. Required by config validation — a `client_credentials` client without `serviceSubject` and `tenant` fails startup validation. | In `config/service-clients.example.yaml`: `tenant:platform` for the platform approval clients, `codex-railiance-platform` and `secrets-engine-openbao` (operator correction, 2026-09-27). |
| Human (`authorization_code`) | The directory user's tenant, falling back to the legacy workload default when unset. | Directory value, else `tenant:coulomb`. |
`tenant`, `tenant_hint`, `audience` and `resource` request parameters cannot
change the claim. `tenant_hint` on `/authorize` reaches registration/enrollment
@ -47,7 +47,9 @@ The decision changed the `tenant` field on exactly two registrations,
entries in `docs/approval-engine-provisioning-request.yaml`. Deliberately
unchanged:
- `codex-railiance-platform` and `secrets-engine-openbao` keep `tenant:coulomb`.
- Historical exception superseded 2026-09-27: `codex-railiance-platform` and
`secrets-engine-openbao` belong to `tenant:platform`; see the OpenBao contract.
Apply the issuer/role/consumer changes in a coordinated deployment window.
- Human directory resolution keeps its `tenant:coulomb` default.
- No cross-tenant grant is implied: a `tenant:platform` token conveys no reach
into `tenant:coulomb` resources, and audiences, scopes, subjects, roles,