Granular Role Permissions

[Danny-Cooke-CK]

The standard AzureTRE roles don't fit some organisations roles and responsibilities or use cases.

We would like to see more granular RBAC permissions within the TRE as follows :-
Researcher
++ Can log onto all VM's within a workspace
++ Can view workspace cost API
-- Can't create airlock requests
-- Can't view airlock request
-- Can't create VM's
Workspace Owner
++ Can log onto all VM's within a workspace
++ Can create VM's within a workspace
++ Can view workspace cost API
-- Can't view airlock request
-- Can't create airlock requests
Airlock Data Engineer
++ Can log onto all VM's within a workspace
++ Can create airlock requests
++ Can view airlock request
Airlock Manager
++ Can log onto all VM's within a workspace
++ Can create VM's within a workspace
++ Can approve airlock requests
-- Can't create airlock requests

We have considered approaching this separately via both organisations using their own forks but to ensure we have a consistent approach and so that it can benefit the community its best approach this centrally.

We need to raise this Git request to ensure that organizations are aware of it and can incorporate it into their current decision-making and roadmap.

[marrobi]

Hi @Danny-Cooke-cCK not sure the model you suggest will work across customers as it's rigid - in the way that some customers need Researchers to create airlock requests.

The actual permissions, such as "Airlock Request Creator", "User Resource Creator" would need to be defined in Azure AD as AD roles, or alternatively we have some way to assign these granular permissions - or actually API routes - to the roles as part of configuration.

Do you think you could maybe have a think along those lines and the pros and cons of both approaches?

[Danny-Cooke-CK]

Interesting yes leave it with me. Would it be reasonable for a researcher in one organisation to have "Researcher" and in another they could have "researcher" + "Airlock requestor" ?

[TonyWildish-BH]

adding some things we've discussed privately, for visibility:

• We'd like to be able to grant/deny access to some workspace templates, depending on the domain. This can help keep the template catalogue manageable when we have large numbers of templates but projects that don't span the entire space of possibilities.
• Within workspaces, we'd like the possibility to limit the resources that some users can deploy, but not others. E.g., not allowing someone to deploy an expensive VM if they're new to the team and not yet familiar with the implications.
• We'd also like the ability to group workspaces (and therefore their members) into teams, where teams may be able to share resources among their own workspaces, but not with other workspaces outside their team.

This should ideally be managed by roles and policies, not workflows and approvals. Approvals should only be needed for changing the level of access, so rarely, to minimise overhead.

[marrobi]

@Danny-Cooke-cCK Maybe take a look at https://casbin.org/ - there are solutions out there to help with more complex permission models.

We likely need something that maps roles, to permissions.

@TonyWildish-BH I think you are asking for three different features there - linked to template permissions/policies and resource sharing, which are different to Danny's ask re API RBAC?

[marrobi]

@Danny-Cooke-cCK been thinking about this, and the easiest way might be to add addition granular roles, like Airlock.Create , Airlock.Approve, Airlock.Read etc to the Workspace Azure AD application. See this example https://learn.microsoft.com/en-us/entra/identity-platform/howto-add-app-roles-in-apps#app-roles-ui where they have Survey.Create.

We could keep the existing Researcher roles as an easier way to get started.

This file (and the route dependencies would need amending) - api_app/services/authentication.py.

Does that make sense?

[Danny-Cooke-CK]

@marrobi it does yes thanks. we are having internal discussions around it now. What would be good though is if we could abstract the permissions up to parameters within the github pipeline. So using the 3 current roles as example (researcher / owner / airlock manager), each of those roles could be defined differently then from one org to the next without having to edit the code

[marrobi]

Then rather than including the granular permissions in Azure AD there would need to be some sort of mapping file of AD App roles to TRE API routes and actions. Something like:

Researcher:
   - GET:/workspace/{id}
   - GET:/workspace/{id}/workspace-service/{id}
   ...
WorkspaceOwner:
   - GET:/workspace/{id}
   - GET:/workspace/{id}/workspace-service/
   - POST:/workspace/{id}/workspace-service/
   - PATCH:/workspace/{id}/workspace-service/{id}
   ...

In the authorization code it would need to get the route and action from the request and match it against the routes allowed for the users roles.

This is the sort of thing that https://casbin.org/ or similar project could potentially help with.

Needs a spike to compare the options. Would also need a good set of tests for each role to ensure initial configuration matches the current roles and permissions.

[marrobi]

See: https://dev.to/teresafds/authorization-on-fastapi-with-casbin-41og

[Danny-Cooke-CK]

i see what you mean now. ok leave it with me