[RHCLOUD-47173] Write the "Migrate Existing Applications to RBAC" How To Guide - #131
[RHCLOUD-47173] Write the "Migrate Existing Applications to RBAC" How To Guide#131Ellen-Yi-Dong wants to merge 2 commits into
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Comment |
|
|
||
| ### Permission schema | ||
|
|
||
| - [ ] Write `.ksl` permission definitions using `@rbac.add_v1_based_permission()` for permissions that need wildcard support |
There was a problem hiding this comment.
Do we want to add @rbac.add_unified_permission and tell the difference there?
| The Default workspace represents "all resources in this organization that aren't explicitly placed elsewhere." By checking permissions against the Default workspace, your application gets org-wide authorization that matches the current behavior: | ||
|
|
||
| <Steps> | ||
| 1. Look up the Default workspace ID for the tenant using `GET /api/rbac/v2/workspaces/?type=default`. Cache this value — it never changes for a given tenant. |
There was a problem hiding this comment.
use with_ancestry=true to bypass validation
| - **Add a `workspace_id` column early** — Even if every resource points to the Default workspace initially, having the column makes future migration straightforward. | ||
| - **Use role bindings, not direct grants** — All access must go through role bindings on workspaces or tenants. This is how Kessel's authorization graph works; there is no mechanism for granting permissions directly on individual resources. | ||
|
|
||
| For guidance on structuring your permission schema, see [Design Permissions Schema](/docs/building-with-kessel/how-to/design-permissions/). |
There was a problem hiding this comment.
The ref file is TODO, is it in a followup?
There was a problem hiding this comment.
Yesh, this reference is to a different task currently given to William Scalf attached here! https://redhat.atlassian.net/browse/RHCLOUD-47172?xpis=eyJicmlkZ2UiOiJzbWFydExpbmtzIiwiaWQiOiIxNzg3NzgxNjc0NTQ0Iiwic291cmNlIjoiamlyYS1KU1cifQ%3D%3D
|
|
||
| The Default workspace represents "all resources in this organization that aren't explicitly placed elsewhere." By checking permissions against the Default workspace, your application gets org-wide authorization that matches the current behavior: | ||
|
|
||
| <Steps> |
There was a problem hiding this comment.
Do you think it worth to add instructions of auth here? "explanation lives in migrate-from-rbac-v1-to-v2.mdx (lines 188–195) and migration-pattern-reference.md (lines 362–364)"
There was a problem hiding this comment.
I think that it might be repeating information if we want to keep it concise?
I can add like a "tip" box and a direct link to the information for more information about the configuring the Kessel client endpoints and authentication credentials if that might help provide a clearer direction?
2 participants
Related JIRA link: https://redhat.atlassian.net/browse/RHCLOUD-47173
Acceptance Criteria as listed within the task:
File: src/content/docs/building-with-kessel/how-to/migrate-to-rbac.mdx
Description: This page is a TODO stub focused on migration patterns for existing applications adopting Kessel RBAC for the first time.
Acceptance Criteria: