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.
3 KiB
tenant-engine Action Vocabulary
This document defines the action vocabulary for tenant-engine as a
flex-auth protected system (FLEX-WP-0008-T01). Action names here match
tenant-engine's own authz.FlexAuthWriteAuthorizer mapping exactly
(tenant_engine/src/tenant_engine/authz.py) — coordinated between the two
repos, not independently invented.
| Action | tenant-engine write endpoint | Resource type | Decision effects |
|---|---|---|---|
tenant.create |
POST /tenants |
tenant |
allow, deny |
tenant.role.grant |
POST /tenants/{id}/roles/grant |
role-grant |
allow, deny |
tenant.role.revoke |
POST /tenants/{id}/roles/revoke |
role-grant |
allow, deny |
tenant.plan.assign |
POST /tenants/{id}/plan |
plan-assignment |
allow, deny |
tenant.update |
PATCH /tenants/{id} |
tenant |
allow, deny |
tenant.retire |
POST /tenants/{id}/retire |
tenant |
allow, deny |
tenant.reactivate |
POST /tenants/{id}/reactivate |
tenant |
allow, deny |
tenant.guardrail.read |
GET /tenants/{id}/guardrails |
guardrail |
allow, deny |
tenant.guardrail.set |
PUT / DELETE /tenants/{id}/guardrails/{limit_key} |
guardrail |
allow, deny |
The lifecycle trio is from FLEX-WP-0010 / TEN-WP-0005. The last two are
the TEN-WP-0006 guardrail actions (FLEX-WP-0014). They are two actions
rather than one tenant.guardrail so policy can grant a PDP the read
without granting the write. That split is used today: flex-auth may
tenant.guardrail.read and may not tenant.guardrail.set; tenant-engine
may do both. Reasoning is recorded in
examples/tenant-engine/policy_package.md.
These are the only nine actions tenant-engine sends to POST /v1/check —
its FlexAuthCheckClient (TEN-WP-0003) never sends anything else.
tenant-engine's role reads (/roles, /roles/live) are still not gated
through flex-auth; they remain tenant-engine's own cache-read and
live-lookup endpoints. The guardrail GET is different: it is authorized,
because a ceiling is an input to a decision, not an unauthenticated lookup.
Not in scope for this vocabulary
tenant-engine's capability roles (PLTF/IAM/VEN/CUS, ADR-0014) are
tenant state — what a tenant is allowed to do on the platform. This
vocabulary governs a different question: which operator/service
subjects are allowed to call tenant-engine's admin API at all. The
lifecycle actions do not change that boundary: tenant.retire asks whether
this caller may retire a tenant, not what a retired tenant may still do —
the latter is tenant state that tenant-engine enforces itself. The two
must not be conflated — a policy package that checked a caller's action
against a tenant's capability roles would be checking the wrong thing.
See examples/tenant-engine/policy_package.md's Rules section for how the
distinction is enforced.
Related
docs/tenant-engine-resource-namespace.mdexamples/tenant-engine/