coulomb/flex-auth
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
flex-auth/docs/tenant-engine-resource-namespace.md
tegwick f304688d72
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 39s
Details
CI Smoke / host-smoke (push) Successful in 1s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details
Authorize tenant-engine guardrail read and set actions 
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.
2026-08-16 02:46:25 +02:00

2.1 KiB
Raw Permalink Blame History

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

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)