docs(authz): custom resource loading and role inheritance#1713
Conversation
Add a doc covering how custom resource types are registered, what SpiceDB rules the bootstrap generator creates for each action, and which role each action ends up with. It also explains why an Org Admin can list resources but cannot get a single one: listing accepts app_project_get as org-wide visibility, while the per-resource get check does not. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a "project-level actions" section explaining that create and list are not special permissions. By RBAC nature they need an object to check against, and the natural object is the container (the project), not a not-yet-created item or a single item. Document the user/project namespace as a config-legal proxy for app/project, since app/* permissions cannot be added from config, with a compute/machine example for create and list. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds a new MDX documentation page about custom resource authorization, covering schema bootstrap, generated permission rules, role inheritance, the ChangesCustom Resources Authorization Documentation
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ad01aca0-a127-489d-9266-8ee8529458a1
📒 Files selected for processing (1)
docs/content/docs/authz/custom-resources.mdx
Remove the "listing vs getting" section. The list-can-succeed-while-get-fails behaviour it described is likely a bug, not something to document as expected. Replace the mermaid load-flow diagram with a plain-text diagram so it renders the same in light and dark theme. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Coverage Report for CI Build 28777571430Coverage remained the same at 44.865%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 118547e3-ec36-401c-8807-1a757d1b759a
📒 Files selected for processing (1)
docs/content/docs/authz/custom-resources.mdx
- Note that boot merges permissions already in Postgres (including ones added via CreatePermission), so a restart does not drop them. - Count the generated targets as five (resource, org, project, role binding, role), not four. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Explain that owners and admins get every custom action by default through the generated rules, while other roles get nothing until granted. Show config for both adding an action to a built-in role (which replaces its permission set) and making a new custom role. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- State that custom actions never need listing on admin roles, since app_project_administer / app_organization_administer already grant them through the schema. - Remove the non-existent "Project Member" role; predefined project roles are Owner, Manager, Viewer only. - Link mentions of the generated rules to the "What rules get generated" section. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Org roles are titled Owner / Admin / Member (not "Org Owner" etc.); keep the internal slug in brackets to tell them apart from the project roles. - Rename the example list action to listcomputemachines (plural). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The role-inheritance (list-vs-get) section was removed, so the title no longer fit. The article is about loading custom resources, the generated permission rules, and which roles get which actions. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Address review feedback on the custom resources doc: - Proxy namespace: state that the name is a free choice. The generator mirrors every custom permission onto app/project and app/organization regardless of namespace, so there is no convention to follow. user/project is just the example. - Admin roles: use the titles and names from PredefinedRoles everywhere, so Owner (app_organization_owner), Admin (app_organization_manager), Project Owner (app_project_owner), and platform admin are no longer ambiguous. - Built-in role permissions: clarify that "already had" means the predefined role defaults, not the base schema. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
♻️ Duplicate comments (1)
docs/content/docs/authz/custom-resources.mdx (1)
384-385: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winStale duplicate wording in Quick Reference contradicts the proxy explanation.
Line 385 still reads "project-level actions (
create,list) live onuser/projectand are checked against the project." A past review flagged this exact phrasing (previously at old line 279 in the "Rule of thumb" section) as misleading, sinceuser/projectis only the config-time authoring namespace — the generator mirrors the permission ontoapp/project, which is where the check actually runs. That earlier occurrence was corrected (now Lines 268-276), but this duplicate copy in the closing Quick Reference summary was missed and still contains the unfixed wording.Suggested fix
- Per-item actions (`get`, `update`, `delete`) live on the resource namespace; project-level - actions (`create`, `list`) live on `user/project` and are checked against the project. + actions (`create`, `list`) are defined under `user/project`, then mirrored onto + `app/project`, where the checks actually run.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 41b71f98-e392-4cae-8ae2-55a90ca8afba
📒 Files selected for processing (1)
docs/content/docs/authz/custom-resources.mdx
What
Adds a new authz doc:
docs/content/docs/authz/custom-resources.mdx.It explains how custom resource types work end to end.
Notes