A policy-as-code capable authorization registry/control-plane service.
tegwick
0bc624ba62
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 |
||
|---|---|---|
| .claude/rules | ||
| .forgejo/workflows | ||
| .github/workflows | ||
| .repo-manager | ||
| charts/flex-auth | ||
| cmd/flex-auth | ||
| decisions | ||
| deploy | ||
| docs | ||
| examples | ||
| history | ||
| intakes | ||
| internal | ||
| pkg/api | ||
| railiance | ||
| registry | ||
| schemas | ||
| tests | ||
| tools | ||
| values | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .golangci.yml | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| Containerfile | ||
| go.mod | ||
| go.sum | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SCOPE.md | ||
| tenancy.yaml | ||
| WORK-RECORDS.md | ||
flex-auth
Policy-as-code authorization registry and control plane for NetKingdom-aligned systems.
Start with INTENT.md for the project boundary and direction. Research notes and ADRs live in docs/ and docs/adr/.
The product boundary is captured in SCOPE.md, and the current Product Requirements Document is docs/ProductRequirementsDocument.md.
The 2026-05-15 pre-implementation assessment that shapes the current sequencing is in docs/pre-implementation-assessment.md.
The CARING reference-implementation approach is captured in docs/caring-architecture-blueprint.md.
Workplans live in workplans/, with sequencing captured in docs/workplan-planning-map.md.