secrets-engine's first live request rejected our allow: binding. request_digest is computed over material they never sent, because we enrich subject and resource from the registry before hashing. Answering that meant reading the enrichment path, which had a worse defect in it. Enrichment was additive-if-absent — addAttribute wrote a registry value only where the request had no value for that key. So where a caller supplied a key, the caller's value won and the registry's never applied. Every registry ceiling and allowlist was advisory. Verified against the shipped ops-warden package, each one added key on an otherwise-denied request: max_ttl_hours: 99 registry says 8 -> allowed a 12h certificate allowed_principals registry allowlist -> disallowed_principal bypassed allowed_subjects registry allowlist -> unknown_subject bypassed The third is the one to read twice: a subject the registry does not know authorized itself by naming itself in the allowlist it was being checked against. Not remotely reachable today — the PEP builds the CheckRequest, ops-warden sends no resource.attributes, and enforce admits one identity. It is a defence-in-depth failure: any path that lets attacker-influenced data into a CheckRequest field became a full policy bypass rather than a bounded input problem. Callers sending resource.attributes is not hypothetical; secrets-engine does it on every request. Registry facts now win, and diagnostics.registry_overrode names every displaced key, because a registry that silently discards a contradicting claim hides that a caller asserted authority it did not have. subject.type is carved out, and the reason is a finding of its own. Making the registry win there denied every secrets-engine allow: the registry's type is CARING vocabulary (Human, Agent, Automation, Service) and the request's is the protected system's actor vocabulary (service, adm, agt, atm). Two fields sharing a name; substituting one for the other is translation rather than identity, which GH-DEC-2026-008 ruled against. Note what surfaced it — the registry's type had been dead data since the field existed, because the caller's value always won. Also publishes binding.submitted_request_digest, over the request exactly as sent. request_digest was published as the consumer replay test and cannot be one. Nothing is lost hashing the pre-enrichment form: enrichment is a function of the request and the snapshot, and registry_snapshot_digest already pins the snapshot. Existing pins do not move. All three replay fixtures' request_digest and approval_binding_digest values are byte-identical — those requests contradict no registry fact. A field to add, not a value to correct. Regression tests verified failing against the old behaviour before being kept. FLEX-DEC-2026-012; FLEX-WP-0025 carries the residual, that a policy still cannot tell a fact from an assertion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd Assistant: claude-code Assistant-Model: opus Assistant-Process: 715613@bnt-lap001 Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
106 lines
3.4 KiB
JSON
106 lines
3.4 KiB
JSON
{
|
|
"id": "decision:7d56b7fc274ddfd6",
|
|
"contract_version": "flex-auth.decision-record.v1",
|
|
"request_id": "check:secrets-engine-wrong-tenant",
|
|
"effect": "deny",
|
|
"reason": "wrong_tenant",
|
|
"matched_policy_version": "v2",
|
|
"matched_rule": "wrong_tenant",
|
|
"resource": {
|
|
"id": "lane:glas-primary",
|
|
"type": "secret-catalog-lane",
|
|
"system": "secrets-engine",
|
|
"tenant": "tenant:coulomb",
|
|
"attributes": {
|
|
"auth_targets": [],
|
|
"fields": [
|
|
"password"
|
|
],
|
|
"policy_targets": [],
|
|
"stage": "prod"
|
|
}
|
|
},
|
|
"subject": {
|
|
"id": "secrets-engine",
|
|
"type": "service",
|
|
"tenant": "tenant:platform",
|
|
"attributes": {
|
|
"description": "secrets-engine's own service identity, the single calling identity for the twelve gated catalog-lane actions it sends to POST /v1/check. Because it is the only subject, the package has no action_not_granted branch (FLEX-WP-0021-T02); registering a second identity is the revisit trigger.",
|
|
"display_name": "secrets-engine service principal",
|
|
"groups": [
|
|
"group:secrets-engine-lane-operators"
|
|
],
|
|
"organization_relation": "ServiceProvider",
|
|
"roles": [
|
|
"Operator"
|
|
]
|
|
}
|
|
},
|
|
"binding": {
|
|
"tenant": "tenant:coulomb",
|
|
"subject": {
|
|
"id": "secrets-engine",
|
|
"type": "service",
|
|
"tenant": "tenant:platform",
|
|
"attributes": {
|
|
"description": "secrets-engine's own service identity, the single calling identity for the twelve gated catalog-lane actions it sends to POST /v1/check. Because it is the only subject, the package has no action_not_granted branch (FLEX-WP-0021-T02); registering a second identity is the revisit trigger.",
|
|
"display_name": "secrets-engine service principal",
|
|
"groups": [
|
|
"group:secrets-engine-lane-operators"
|
|
],
|
|
"organization_relation": "ServiceProvider",
|
|
"roles": [
|
|
"Operator"
|
|
]
|
|
}
|
|
},
|
|
"action": "rotate",
|
|
"resource": {
|
|
"id": "lane:glas-primary",
|
|
"type": "secret-catalog-lane",
|
|
"system": "secrets-engine",
|
|
"tenant": "tenant:coulomb",
|
|
"attributes": {
|
|
"auth_targets": [],
|
|
"fields": [
|
|
"password"
|
|
],
|
|
"policy_targets": [],
|
|
"stage": "prod"
|
|
}
|
|
},
|
|
"request_digest": "sha256:c9c6e6f8713266e9e95ae1443a395a3a1f965ba95469dea747645f0437bb0d20",
|
|
"submitted_request_digest": "sha256:9aab6de9069e1e811a52835ca00bc5e9cb38166444df068eb60a26923b1c9175"
|
|
},
|
|
"diagnostics": {
|
|
"action": "rotate",
|
|
"matched_relationship": "",
|
|
"policy_package": "secrets-engine.catalog-lane.lifecycle",
|
|
"policy_status": "ready",
|
|
"registry_overrode": [],
|
|
"registry_resource": false,
|
|
"registry_subject": true
|
|
},
|
|
"provenance": {
|
|
"evaluator": "flex-auth/local",
|
|
"mode": "standalone",
|
|
"policy_package": "secrets-engine.catalog-lane.lifecycle",
|
|
"policy_version": "v2",
|
|
"policy_package_digest": "sha256:bd11c5fe77ce6439c65fea225ad6b71d2110efc5e7b5bc9b499c59cd0a53b8b4",
|
|
"registry_snapshot_digest": "sha256:f5a309bc0b36721fd6d9ad7f53eb21222162bc2eac62a0ab0802a9a1d51340bb",
|
|
"decision_time": "2026-09-07T07:10:24Z"
|
|
},
|
|
"caring": {
|
|
"profile": "caring-0.4.0-rc2",
|
|
"conformance_findings": [
|
|
{
|
|
"code": "CARING-DESCRIPTOR-MISSING",
|
|
"severity": "warning",
|
|
"message": "no CARING descriptor matched the request",
|
|
"fields": [
|
|
"caring_context"
|
|
]
|
|
}
|
|
]
|
|
}
|
|
}
|