allow TRE Admins to deprecate older template versions by removing access to them, so they can no longer be instantiated.
allow TRE Admins to hold off on making new templates generally available until they've been thoroughly tested in controlled environments
allow Workspace Admins to limit access to workspace services or user resources, within the set allowed for them by the TRE Admin.
allow Workspace Admins to limit access to User Resource choices that are costly, and not needed for the project (e.g. VMs with GPUs)
The first two above only require control at the Workspace Service or User Resource level for the entire template, and can be implemented generically. Access is granted or denied per workspace.
The third option is just a subset of the first two, with reduced scope, to what the Workspace Admin can see.
The fourth option requires control within the template, specific to the User Resource Options/Features available there, and will have to be customised for each template.
Implementing a PoC will require a number of changes, this ticket is for defining what that PoC should look like, as there's a fair bit of design work to do:
The UI presentation needs to be thought out. I've taken a first pass at that, and will update this ticket after it's been discussed more widely
Currently, multiple template versions are allowed for workspaces and services, but one is flagged as current, meaning it's used by default. To use a non-current version, I believe you have to deploy first, then update the resource, though that assumption needs checking. It's not always meaningful to update a template on a running service, so it would be better if the right version were selected at creation-time.
The workspace templates will need updating to maintain an array of permitted values, per service. The user will have to be presented with an option to choose a non-default version if that's what they want to do, and if multiple versions are available to them.
The UI API will have to be updated to look not at the current flag, but at the list of available versions, and act accordingly. This means checking that both the TRE Admin and the Workspace Admin allow this version to be used.
N.B. the list of available versions may be empty, if a service has been declared not to be available to a workspace. How this is handled is something to work out. Either hide the service completely, or grey it out, or ...
Access is currently handled generically at the level of workspace roles (Workspace Admin, Workspace Researcher, Airlock Manager, TRE Admin). We may need to introduce an extra role ("Workspace Newbie"?) if we want to allow the Workspace Admin to grant access to resources differently to different users (e.g. allow person A to use GPUs, but not person B).
One way to handle User Resource Options RBAC is to add new boolean flags, with the meaning of them coded into the template, rather than using a generic mechanism. E.g. instead of allowing the Workspace Admin to say "Don't allow access to VMs that cost over £50/day", which is generic, we might use "Don't allow access to GPUs", which can be handled more easily by filtering out the menu options that have 'GPU' in the name.
This is going to touch a lot of code: UI, API, templates, and maybe the TRE CLI too if we have time.
RBAC for the SDE serves a few functions:
The first two above only require control at the Workspace Service or User Resource level for the entire template, and can be implemented generically. Access is granted or denied per workspace.
The third option is just a subset of the first two, with reduced scope, to what the Workspace Admin can see.
The fourth option requires control within the template, specific to the User Resource Options/Features available there, and will have to be customised for each template.
Implementing a PoC will require a number of changes, this ticket is for defining what that PoC should look like, as there's a fair bit of design work to do:
current, meaning it's used by default. To use a non-current version, I believe you have to deploy first, thenupdatethe resource, though that assumption needs checking. It's not always meaningful to update a template on a running service, so it would be better if the right version were selected at creation-time.currentflag, but at the list of available versions, and act accordingly. This means checking that both the TRE Admin and the Workspace Admin allow this version to be used. N.B. the list of available versions may be empty, if a service has been declared not to be available to a workspace. How this is handled is something to work out. Either hide the service completely, or grey it out, or ...This is going to touch a lot of code: UI, API, templates, and maybe the TRE CLI too if we have time.