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

Enforce RBAC authorization using v1 inventory permissions for workspace endpoints

XMLWordPrintable

    • Product / Portfolio Work
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide

      Reference: https://docs.google.com/spreadsheets/d/1mSRLT4nfOlezcndhLDmG0BKUqMal1_8pUtaK0Sj6DL0/edit?gid=292897041#gid=292897041 

      • Workspace access control should no longer be gated on org-admin (confirm whether or not an org-admin should still be able to act on all workspaces)
      • As a non-admin with read access to workspaces via the "inventory:groups:read" permission without any resource definitions/attribute filters, I should be able to view all workspaces in my org via the API.
      • As a non-admin with write access to workspaces via the "inventory:groups:write" permission without any resource definitions/attribute filters, I should be able to create/update/delete all workspaces in my org via the API. (confirm if this allows creates/deletes, or if you need admin)
      • As a non-admin with admin access to workspaces via the "inventory:groups:*" permission without any resource definitions/attribute filters, I should be able to read/create/update/delete all workspaces in my org via the API.
      • As a non-admin with read access to workspaces via the "inventory:groups:read" permission limited to workspace A and B, I should be able to view workspace A and B in my org via the API, and no others.
      • As a non-admin with write access to workspaces via the "inventory:groups:write" permission limited to workspace A and B, I should be able to update/delete workspace A and B in my org via the API, and no others, and not create a workspace (confirm).
      • As a non-admin with admin access to workspaces via the "inventory:groups:*" permission limited to workspace A and B, I should be able to view/create/update/delete workspace A and B in my org via the API, and no others.
      Show
      Reference: https://docs.google.com/spreadsheets/d/1mSRLT4nfOlezcndhLDmG0BKUqMal1_8pUtaK0Sj6DL0/edit?gid=292897041#gid=292897041   Workspace access control should no longer be gated on org-admin (confirm whether or not an org-admin should still be able to act on all workspaces) As a non-admin with read access to workspaces via the "inventory:groups:read" permission without any resource definitions/attribute filters, I should be able to view all workspaces in my org via the API. As a non-admin with write access to workspaces via the "inventory:groups:write" permission without any resource definitions/attribute filters, I should be able to create/update/delete all workspaces in my org via the API. (confirm if this allows creates/deletes, or if you need admin) As a non-admin with admin access to workspaces via the "inventory:groups:*" permission without any resource definitions/attribute filters, I should be able to read/create/update/delete all workspaces in my org via the API. As a non-admin with read access to workspaces via the "inventory:groups:read" permission limited to workspace A and B, I should be able to view workspace A and B in my org via the API, and no others. As a non-admin with write access to workspaces via the "inventory:groups:write" permission limited to workspace A and B, I should be able to update/delete workspace A and B in my org via the API, and no others, and not create a workspace (confirm) . As a non-admin with admin access to workspaces via the "inventory:groups:*" permission limited to workspace A and B, I should be able to view/create/update/delete workspace A and B in my org via the API, and no others.
    • Unset
    • None
    • 5
    • Access & Management Sprint 106, Access & Management Sprint 107, Access & Management Sprint 108, Access & Management Sprint 109

      This will not only support forwarded requests from HBI -> RBAC for workspaces, but will also be required for supporting direct API requests from the new workspace UI.

      Long-term, we'll be integrating with Kessel to check authorization against RBAC resources (like workspaces) for meta-authz, RBAC-on-RBAC.

      Prior to having the schema and client available to do this, we can take advantage of existing v1 permissions [1] which are currently used by HBI to enforce access control against inventory groups (workspaces).

      We should be able to tap into the workspace access class [2] similar to what we do for other RBAC-on-RBAC checks [3] which is populated in our middleware [4].

      The key difference here is that we'll need to be storing and checking granular access from resourceDefinitions, to restrict access to specific workspaces. We'll need to ensure parity with existing enforcement in HBI today.

      [1] https://github.com/RedHatInsights/rbac-config/blob/master/configs/prod/permissions/inventory.json#L21-L30
      [2] https://github.com/RedHatInsights/insights-rbac/blob/master/rbac/management/permissions/workspace_access.py
      [3] https://github.com/RedHatInsights/insights-rbac/blob/master/rbac/management/permissions/principal_access.py#L33
      [4] https://github.com/RedHatInsights/insights-rbac/blob/master/rbac/rbac/middleware.py#L153

              rh-ee-zhzeng Jay Zeng
              rh-ee-zhzeng Jay Zeng
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: