Isolate workspaces into individual subscriptions

[cricex]

Describe the solution you'd like
As an Information Security Officer
I want each workspace deployed into their own spoke subscription, each user's resources deployed into their own resource group within the workspace's subscription, and service resources deployed into a service resource group within the workspace's subscription
So that we may improve security isolation, billing isolation, and overcome subscription resource limitations

[marrobi]

Thanks, we would be limited to 800 resource groups per subscription. Is that an issue?

The separate resource groups for services and user resources can be handled in the respective templates. So no changes to the TRE APIs, or resources processor are required.

The subscription piece is doable, but work required.

[cricex]

Is 800 a TRE or ARM limitation? The documentation states that there is a limitation of 980 resource groups per subscription. (https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#subscription-limits)

Regardless, I believe 800 or 980 resource groups (and therefore 799 or 979 individual researchers) is sufficiently high limitation for an individual workspace.

[marrobi]

We will refine this feature into stages, separation of workspaces into subscriptions being the most requested ask.

[Danny-Cooke]

This feature has been requested by a third party so will be looking at how to deliver this or assist

[marrobi]

@SvenAelterman @Danny-Cooke is it worth us getting on a call to discuss requirements? Then a design can be posted here and discussed?

[SvenAelterman]

We can. Unfortunately, our project has not progressed.

[marrobi]

This branch shows how this might be done - haven't tested across multiple subscriptions.

https://github.com/marrobi/AzureTRE/tree/marrobi/workspace-different-subscription

Each workspace service would have to use the parent workspace_subscription_id when configuring the provider.

If someone wants to pick it up happy to help.

[TonyWildish-BH]

that looks interesting, thanks Marcus. We may be able to pick this up in the near future, we're mapping out our future strategy for scaling up, hence all the tickets recently.

[SvenAelterman]

I am working with a customer who also needs a solution for 300+ workspaces. The customer is working with a partner on implementation.

I would propose we all work together on the solution? LMK if you'd be open to that.

If so, as a next step, we should individually review Marcus' work so far and then schedule a call to flesh out remaining work items and try to divide the tasks?

[TonyWildish-BH]

I am working with a customer who also needs a solution for 300+ workspaces. The customer is working with a partner on implementation.

I would propose we all work together on the solution? LMK if you'd be open to that.

If so, as a next step, we should individually review Marcus' work so far and then schedule a call to flesh out remaining work items and try to divide the tasks?

I'd be interested, thanks.

[SvenAelterman]

This branch shows how this might be done - haven't tested across multiple subscriptions.

https://github.com/marrobi/AzureTRE/tree/marrobi/workspace-different-subscription

Each workspace service would have to use the parent workspace_subscription_id when configuring the provider.

If someone wants to pick it up happy to help.

We've evaluated this and this approach looks very good.

To extend this, we'd need to use a similar approach with an aliased azurerm provider for each workspace service, I presume? How would we get the subscription ID of the workspace passed on to the bundle for the workspace service without having to ask for it again in the UI?

I think we would use the same way the workspace_id gets passed along, but I can't recall how that happens? Is in the Python code or is it declaratively?

[marrobi]

Correct, could get the workspace subscription ID as discussed here - #4284