feat(arstotzka): v3 statement-based grants, package split, doorman cutover #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "arrdem/arstotzka-v3-cutover"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Arstotzka moves to v3 statement-based grants per SPEC.md — AWS-IAM-style
(actions, resources)per audience, replacing the v2{role: "<name>"}claim lists. The package is split into three sub-projects underprojects/arstotzka/so downstream services pull in only what they need. Doorman is cut over as the one real consumer.What changed
projects/arstotzka/statements/— new standalone package. Pureallows(statements, action, resource)andresource_access_allows(ra, aud, action, resource), zero runtime deps. Import asfrom arstotzka.statements import .... Build target//projects/arstotzka/statements:statements.projects/arstotzka/server/— what wasprojects/arstotzka/src/arstotzka/lives here now. Package patharstotzka.server.*. v3 config loader rejects v2 at startup;validate_tokenemits a fullresource_accessslice scoped to the forwarded host. Token narrowing is authctl-enforced as a subset of the user's grants, so the server emitstoken.grantsdirectly with no runtime intersection./assets/logo.svg+ favicon/banner on the login page.projects/arstotzka/cli/— authctl learns v2→v3 migration (synthesizes per-(role, host)role templates), newrole define/list/show/removegroup,user grant/revoke,token grant/revoke-grant.token add --grantreplaces--service host:role.token grantrejects roles the user doesn't have so the subset invariant holds.projects/doorman/—_extract_prioritynow probes the v3resource_accessslice atollama.tirefireind.usfor(queue, priority:<level>)in descending order, highest wins. Tests updated. Depends on//projects/arstotzka/statements.Changes are visible to end-users: no
Infrastructure change. No API surface changes for human users until arstotzka is redeployed.
X-Auth-Context.rolesbreakCutover plan
The v2 → v3 switch is atomic at the wire format, so any Arstotzka-fronted RP that parses
X-Auth-Contextmust land its v3 reader before (or with) this:authctl migrateagainst the 1P config, review the 7 auto-synthesized roles, rename/tighten as desired, push.ollama-quota-{max,high,normal,low}) with statements{actions:["queue"], resources:["priority:<level>"]}onollama.tirefireind.us, grant them to the appropriate users, revoke the auto-synthesizedollama-tirefireind-us-quota-*stand-in. The wildcard-allow template lets doorman matchpriority:maxby accident today, so migrated configs aren't broken, just imprecise.bazel run //projects/arstotzka:deploy).bazel run //projects/doorman:deploy).flowmetalrepo —crates/frontend/src/auth.rsswitches from role-string matching to(action, resource)probing. Roll that out right after arstotzka.Test plan
authctl migratesmoke-tested against a snapshot of the production config — 19 users, 19 tokens, 7 roles synthesized, deep-equal to the hand-constructed expected output.04e758c93dto454b1956a2arrdem referenced this pull request2026-04-23 18:04:02 +00:00