RBAC for template access control

[TonyWildish-BH]

This is something we've already started work on, would like to get other people's opinions.

Currently, the TRE supports only one current version of a template at a time, with that flag being TRE-wide for the given template. This makes it impossible to test newly-introduced services in the production instance without making them generally available. We want to replace that mechanism with something more flexible.

The requirements we're working to are:

1. A TRE Admin should be able to enable/disable use of a template-version per workspace. This may result in zero, one, or more than one version of a given template being available to the workspace. This allows the TRE Admin to enable a new template or template version in one workspace, where they test it, and then introduce it to other workspaces in a controlled manner.
2. When a template is instantiated in a workspace, by default, the highest enabled version in that workspace should be used.
3. We may want to allow the Workspace Admin to create a different version from the highest, if there's another version enabled. They may need that for compatibility or continuity.
4. The Workspace Admin may want to restrict the set of services available to their Researchers. E.g., they may not want them to be able to use AzureML, in case they spend too much money on compute.
5. Same as 4, but with a twist. The Workspace Admin may want to restrict the set of VM sizes available to Researchers. E.g., to not allow them to use expensive machines such as those with GPUs. I call this out separately because the work to implement it will be different to that for a workspace service.

This requires an extension to the workspace document in CosmosDB. We're thinking along the lines of adding a block like this:

[
 {
  "name": "tre-service-guacamole",
  "title": "Apache Guacamole - Virtual Desktop Service",
  "versions": [
   {
    "version": "0.12.6",
    "description": "Enables Windows and Linux virtual machines to be accessed via Apache Guacamole.",
    "enabled": {
     "TRE": false,
     "Workspace": false
    }
   },
 {
    "version": "1.20.2",
    "description": "Enables Windows and Linux virtual machines to be accessed via Apache Guacamole.",
    "enabled": {
     "TRE": true,
     "Workspace": true
    }
  ],
  "user-resources": [
   {
    "name": "tre-service-guacamole-linuxvm",
    "versions": [
     {
      "version": "1.2.3",
      "description": "Linux virtual machine.",
      "enabled": {
       "TRE": false,
       "Workspace": false
      }
     }
    ]
   },
   {
    "name": "tre-service-guacamole-windowsvm",
    "versions": [
     {
        ...   
     } 
  ]
},
{
  "name": "tre-service-databricks",
  "title": "Azure Databricks",
  "versions": [
    ....
  ],
  ....
 }
]

When a service is to be instantiated, by whoever it is, the list of versions that are allowed by both the TRE Admin (version.enabled.TRE) and the Workspace Admin (version.enabled.Workspace) is retrieved, and the highest version number wins (or, stretching a bit, the user is offered a choice).

The UI and the Resource Processor will both need some work to pull out and run the correct version, instead of using the current flag as at the moment.

Managing the set of versions can be implemented in three phases:

1. In the first case, only supporting the TRE Admin, we can use standalone scripts to manipulate the flags per workspace.
2. Once we know what we're doing, we can embed this in the tre CLI for easier use.
3. Finally, one day, we can build a UI page to represent the versions as checkboxes, giving views for TRE Admins and also Workspace Admins, if we get that far.

The absolute minimum we need is to satisfy requirements 1 and 2 above, with the first phase of implementation being adequate. With that, we can control the release of new versions of templates without risk to our users if something goes wrong.

I'd be very interested to hear opinions on this.

[marrobi]

@TonyWildish-BH

On:

The Workspace Admin may want to restrict the set of services available to their Researchers. E.g., they may not want them to be able to use Azure ML, in case they spend too much money on compute.

I'm not sure what you mean? Surely Azure ML would just not be deployed into the workspace?

Can I suggest that we start with "As a TRE Admin I want to be able to define which templates can be deployed into a workspace by a Workspace Owner", rather than boil the ocean.

I would see something like:

"allowedChildResources": [
    { 
        "name": "tre-service-azureml"
    }
]

We can then check for the presence of the "allowedServices", if not there, allow all (for backwards compatibility), if it is there then check the service name is listed before deploying.

We can then move forward to look at versions, and another ask is maximum number of each type of child resource.

[TonyWildish-BH]

True, in the current model, it's enough to simply not deploy the resource. However, features for the Workspace Admin are mostly a byproduct of what's needed for the TRE Admin, this is buy-one-get-one-free.

The primary motivation for this work is for the TRE Admin to be able to control the introduction and deprecation of resource versions in a controlled manner, per workspace.

Testing new versions in development environments is fine, but they should also, always, be tested in production before making them generally available. This approach, having a boolean flag for each (workspace, resource, version) triple allows that to be done properly. Making it two flags, instead of one, allows the possibility of extending this to functionality that the Workspace Admin is likely to want in future.