3.2 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 endpoint | Resource type | Decision effects |
|---|---|---|---|
tenant.read |
GET /tenants/{id} |
tenant |
allow, deny |
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.role.read |
GET /tenants/{id}/roles |
role-grant |
allow, deny |
tenant.role.read.live |
GET /tenants/{id}/roles/live |
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 twelve actions tenant-engine sends to POST /v1/check —
its FlexAuthCheckClient (TEN-WP-0003) never sends anything else.
Every tenant and role read is gated before the store is touched, preventing
both unauthorized data access and tenant-existence probing. user-engine
may read tenant records, flex-auth may perform the high-stakes live role
lookup, and no caller receives a role-read privilege through a mutation rule.
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/