coulomb/flex-auth
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Authorize tenant-engine guardrail read and set actions
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details
Build and Publish Container Image / build-and-push (push) Successful in 39s
Details

Browse source 
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.
This commit is contained in:
tegwick 2026-08-16 02:46:25 +02:00
parent 8563c17a9f
commit f304688d72
13 changed files with 627 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

21
docs/tenant-engine-resource-namespace.md
View file

@ -5,13 +5,13 @@ 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) 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.
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
@ -19,10 +19,13 @@ omission.
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 three are `scope_level: Resource`, always accessed within
`system: tenant-engine`.
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