tegwick
f304688d72
FLEX-WP-0014. Package tenant-engine.write-api.mutate v1 now carries nine actions: tenant.guardrail.read and tenant.guardrail.set on resource type guardrail, verbatim from tenant-engine's mapping. The read/write split is used now: flex-auth may read ceilings and is denied action_not_granted on set; tenant-engine may do both. 17/17 Rego tests and 23/23 fixtures pass. Live e2e against a real tenant-engine FlexAuthWriteAuthorizer matches. In source only; production still serves the seven-action 9320df39 pin.
48 lines
2.1 KiB
Markdown
48 lines
2.1 KiB
Markdown
# tenant-engine Resource Namespace
|
|
|
|
This document defines the `tenant-engine` protected-system namespace
|
|
consumed by flex-auth (`FLEX-WP-0008-T01`).
|
|
|
|
Unlike Markitect's document hierarchy or ops-warden's fixed SSH-certificate
|
|
inventory, `tenant-engine`'s resources (tenants, their role grants, their
|
|
plan assignments, their guardrails) are created **dynamically** — there is
|
|
no fixed, pre-registrable resource list to publish a
|
|
`resource_manifest.yaml` for. Every `CheckRequest` carries the resource
|
|
identity inline (`resource.id == tenant_id`), and the policy evaluates
|
|
against `input` directly rather than looking up a registered resource by
|
|
id. This is a deliberate, documented deviation from the ops-warden
|
|
pattern, not an omission.
|
|
|
|
## Resource Types
|
|
|
|
```text
|
|
tenant -- a tenant record (existence, grouping)
|
|
role-grant -- a capability-role grant/revocation
|
|
plan-assignment -- a tenant's plan/subscription assignment
|
|
guardrail -- a tenant's resolved ceiling and its provenance
|
|
```
|
|
|
|
All four are `scope_level: Resource`, always accessed within
|
|
`system: tenant-engine`. A guardrail check still sends `resource.id` equal
|
|
to the tenant id — there is no separately addressable guardrail object on
|
|
the wire.
|
|
|
|
## Ownership Boundary
|
|
|
|
`tenant-engine`'s own boundary contract
|
|
(`net-kingdom/canon/standards/tenant-engine-boundary-contract_v0.1.md`)
|
|
already defines these as `tenant-engine`'s owned resource kinds. This
|
|
namespace only maps that ownership into flex-auth's protected-system
|
|
vocabulary — it does not redefine ownership.
|
|
|
|
## Related
|
|
|
|
- `docs/tenant-engine-action-vocabulary.md` — the actions gated on these
|
|
resource types
|
|
- `examples/tenant-engine/` — protected-system manifest, subject manifest,
|
|
policy package, and fixtures
|
|
- `net-kingdom/docs/adr/ADR-0014-tenant-capability-roles-and-tenant-engine-ownership.md`
|
|
— the capability-role model (`PLTF`/`IAM`/`VEN`/`CUS`) these resources
|
|
carry as *tenant* state, distinct from the *operator* authorization this
|
|
namespace governs (who may call `tenant-engine`'s write API, not what a
|
|
tenant is allowed to do)
|