FLEX-WP-0008 T01-T02: tenant-engine resource/action vocabulary + policy package
docs/tenant-engine-{resource-namespace,action-vocabulary}.md: four actions
(tenant.create, tenant.role.grant, tenant.role.revoke, tenant.plan.assign)
matching tenant_engine/src/tenant_engine/authz.py's _RESOURCE_TYPES mapping
exactly. No resource_manifest.yaml -- tenant-engine's resources are created
dynamically, unlike ops-warden's fixed SSH-certificate inventory; documented
as a deliberate deviation.
examples/tenant-engine/: protected_system_manifest.yaml, subject_manifest.yaml
(one registered caller: tenant-engine's own service identity),
policy_package.md (Rego rules + embedded tests), policy_fixtures.yaml (8
allow/deny pairs), assembled registry_snapshot.json, two standalone
check_request examples, README.
Design decision made explicit in the workplan: operator/service-identity
authorization (one known subject, four known actions), not aal2+assurance +
tenant-capability-role checking -- CheckRequest carries no assurance claim
yet (TEN-WP-0003 already flagged actor as a plain request-body field, not a
real auth context), and a tenant's capability roles are the tenant's own
state, not a property of who may call tenant-engine's admin API. Revisit
once KEY-WP-0005 gives callers a real assurance-bearing identity.
Verified for real: built ./cmd/flex-auth, ran test-policy (6 tests + 8
fixtures, all pass), load-registry, check against both example requests.
Then ran a live flex-auth serve with this exact registry+policy and pointed
tenant-engine's real, unmodified FlexAuthCheckClient/FlexAuthWriteAuthorizer
at it over real HTTP: unknown subject -> 403, tenant-engine -> 201. go test
./... still green across the whole repo.
T03 (live-lookup context adapter for other protected systems) stays open --
new Go adapter package, tracked separately.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
parent
ab0125193f
commit
49de2f40ff
11 changed files with 744 additions and 2 deletions
|
|
@ -16,6 +16,7 @@ related_workplans:
|
|||
- KEY-WP-0005
|
||||
created: "2026-07-23"
|
||||
updated: "2026-07-23"
|
||||
state_hub_workstream_id: "6341d238-fffc-4428-9265-0b6db5714e9b"
|
||||
---
|
||||
|
||||
# FLEX-WP-0008: tenant-engine Consumer Integration
|
||||
|
|
@ -49,8 +50,9 @@ and action vocabulary is small and doesn't need CARING descriptor mapping.
|
|||
|
||||
```task
|
||||
id: FLEX-WP-0008-T01
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "d78361e6-eb8e-4623-bed2-917538c403ca"
|
||||
```
|
||||
|
||||
Resource types: `tenant`, `role-grant`, `plan-assignment`. Actions:
|
||||
|
|
@ -66,12 +68,23 @@ the `markitect-resource-namespace.md` / `markitect-action-vocabulary.md`
|
|||
naming pattern (`tenant-engine-resource-namespace.md`,
|
||||
`tenant-engine-action-vocabulary.md`).
|
||||
|
||||
**Done 2026-07-23:** Both docs written. One deliberate deviation from the
|
||||
ops-warden template, documented in `tenant-engine-resource-namespace.md`:
|
||||
no `resource_manifest.yaml` — ops-warden's SSH certificates are a fixed,
|
||||
pre-registrable inventory; `tenant-engine`'s tenants are created
|
||||
dynamically, so the policy evaluates `input` directly rather than looking
|
||||
up a registered resource by id. Action vocabulary cross-checked against
|
||||
`tenant-engine/src/tenant_engine/authz.py`'s actual
|
||||
`_RESOURCE_TYPES` mapping — the four action strings and their resource
|
||||
types match exactly, not just by convention.
|
||||
|
||||
## Task: Author and register the tenant-engine policy package
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0008-T02
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "8a07e83b-27a2-4390-a169-51065bcf3bd6"
|
||||
```
|
||||
|
||||
Policy: writes require an `aal2`+ assurance actor holding an appropriate
|
||||
|
|
@ -87,12 +100,47 @@ Done when: `POST /v1/check` against a request matching `TEN-WP-0003`'s
|
|||
and `deny` for an unauthorized one, exercised by `main_test.go`-style
|
||||
integration tests.
|
||||
|
||||
**Done 2026-07-23, with the design decision made explicit:** chose
|
||||
**operator/service-identity authorization**, not `aal2`+assurance +
|
||||
tenant-capability-role checking, for this specific policy. Reasoning,
|
||||
recorded here rather than left implicit: `tenant_engine`'s `CheckRequest`
|
||||
today carries no `assurance` claim at all (there's no authenticated caller
|
||||
identity yet — `TEN-WP-0003`'s closure note already flagged `actor` as a
|
||||
plain request-body field, not a real auth context), and a tenant's
|
||||
capability roles (`PLTF`/`IAM`/`VEN`/`CUS`) are a property of the *tenant*
|
||||
being written to, not of *who is allowed to call tenant-engine's admin API*
|
||||
— checking the wrong one would be a category error, the same one flagged
|
||||
in `docs/tenant-engine-action-vocabulary.md`. So: `examples/tenant-engine/policy_package.md`
|
||||
authorizes exactly one registered service subject (`tenant-engine` itself,
|
||||
`subject_manifest.yaml`) for the four known actions against
|
||||
`system: "tenant-engine"`. Revisit once `KEY-WP-0005` gives callers a real
|
||||
`assurance`-bearing identity to check.
|
||||
|
||||
Registered: `protected_system_manifest.yaml`, `subject_manifest.yaml`,
|
||||
`policy_package.md` (Rego rules + embedded tests), `policy_fixtures.yaml`
|
||||
(8 allow/deny pairs), assembled `registry_snapshot.json`, two standalone
|
||||
`check_request_*.json` examples, `README.md`.
|
||||
|
||||
**Verified for real, not just written:** built the actual `flex-auth`
|
||||
binary (`go build ./cmd/flex-auth`) and ran it against every artifact:
|
||||
`test-policy` — all 6 Rego tests and all 8 fixtures pass; `load-registry`
|
||||
loads the snapshot cleanly; `check` against both standalone request files
|
||||
returns the expected `allow`/`deny`. Then went one step further than the
|
||||
task's own done-criteria: ran a **live `flex-auth serve`** with this exact
|
||||
registry+policy and pointed `tenant-engine`'s real, unmodified
|
||||
`FlexAuthCheckClient`/`FlexAuthWriteAuthorizer` at it (`TENANT_ENGINE_FLEX_AUTH_URL`)
|
||||
— `POST /tenants` with `actor="ops"` → `403 unknown_subject`; with
|
||||
`actor="tenant-engine"` → `201`. Full round trip, both processes, real
|
||||
HTTP, real Rego evaluation. `go test ./...` still green across the whole
|
||||
`flex-auth` repo — nothing broken.
|
||||
|
||||
## Task: tenant-engine live-lookup context adapter
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0008-T03
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "20c005a4-48b7-4ac4-a345-aeaa0de06d80"
|
||||
```
|
||||
|
||||
A context-enrichment adapter (mirrors `internal/adapters/{relationship,rule,topaz}`'s
|
||||
|
|
@ -115,6 +163,7 @@ with an empty result.
|
|||
id: FLEX-WP-0008-T04
|
||||
status: todo
|
||||
priority: low
|
||||
state_hub_task_id: "0c59ada6-c61b-41a3-8baa-a98e936c5690"
|
||||
```
|
||||
|
||||
Confirm T01–T03 done; run flex-auth's existing test suite plus the new
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue