Uploaded image for project: 'Hybrid Cloud Console'
  1. Hybrid Cloud Console
  2. RHCLOUD-40955

Create a DDR for this epic

XMLWordPrintable

    • Product / Portfolio Work
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      • Document clear criteria and patterns for binding permissions to the Organization, Root Workspace and Default Workspace: This document will serve as crucial reference documentation, providing explicit guidance for Insights teams and ensuring clear expectations for how permissions map to the Kessel hierarchy
      • Detail what metadata is required in rbac-config to signify what level the permission should be bound to. 
      • Detail how the seeding process on the RBAC side will occur based on the metadata update
      • The documentation should explicitly clarify the reasoning behind the chosen migration patterns for permissions, enhancing understanding and reducing ambiguity
      • Detail how the RBAC migrator will determine the correct placement (binding level) for permissions based on the "highest" permission requirement within a V2 Role, following the hierarchy: Organization > Root Workspace > Default Workspace > Any other level 
      • The document should establish a clear decision-making process or mapping for Insights teams to follow when categorizing their permissions, leveraging insights from prior POCs.
      Show
      Document clear criteria and patterns for binding permissions to the Organization, Root Workspace and Default Workspace: This document will serve as crucial reference documentation, providing explicit guidance for Insights teams and ensuring clear expectations for how permissions map to the Kessel hierarchy Detail what metadata is required in rbac-config to signify what level the permission should be bound to.  Detail how the seeding process on the RBAC side will occur based on the metadata update The documentation should explicitly clarify the reasoning behind the chosen migration patterns for permissions, enhancing understanding and reducing ambiguity Detail how the RBAC migrator will determine the correct placement (binding level) for permissions based on the "highest" permission requirement within a V2 Role, following the hierarchy: Organization > Root Workspace > Default Workspace > Any other level  The document should establish a clear decision-making process or mapping for Insights teams to follow when categorizing their permissions, leveraging insights from prior POCs.
    • Unset
    • None
    • Access & Management Sprint 113, Access & Management Sprint 114, A&M Tech Debt Sprint Q3 2025, Access & Management Sprint 115, Access & Management Sprint 116, Access & Management Sprint 117, Access & Management Sprint 118, Access & Management Sprint 119

      This documentation effort directly informs existing work, such as the spreadsheet (https://docs.google.com/spreadsheets/d/1V3mH2pDgXOcxeyxt0fH8RnzzmDsKRDxKzDxxmuaP1mk/edit?gid=0#gid=0 columns X and Y) which depends on Insights teams filling out relevant columns based on these criteria and insights from past Proof of Concepts (POCs). This spike will provide the definitive rules and patterns on how to update RBAC-config to contain the correct metadata once the correct workspace/org level has been determined for each permission. 

      We can have a list for each level, such as:
      default: app1, app2
      root: app3
      org: app3
      Deploy and consume by the server

              rh-ee-zhzeng Jay Zeng
              kwalsh@redhat.com Keith Walsh
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: