Supply Workspace client secret without having to pass it in the API

[tanya-borisova]

Description

This is a continuation of #2148

After an offline discussion, we agreed that we don't want to be passing secrets from users to the API, as it creates additional problems of storing these secrets and making sure the solution is secure.

The only existing use case for accepting secrets from users is the Workspace Client Secret, which is created when the manual Workspace app registration flow is chosen. This task explores ways how to pass this secret to the Workspace bundle without having to persist it in the API.

Note: This discussion is only relevant for when Workspace App Registrations are created manually. When they are created automatically, there's no secret to pass.

Flow

1. AAD Tenant Admin creates Workspace App Registrations. This creates the Service Principal and outputs the secret, WORKPACE_API_CLIENT_SECRET.
2. AAD Tenant Admin then passes on this secret to somebody who has Azure Contributor role assigned (this can be TRE Admin, or not).
3. Azure Contributor then puts the secret in the Keyvault. There are two options on which Keyvault to choose (see below). They need to either use a pre-defined naming scheme to name this secret, or remember the name of the secret.
4. Later on, when the workspace is created, the name of the secret is passed in instead of the "client_secret" field.

Option 1: Core keyvault

In this option, Azure Contributor puts the secret into Core Keyvault in step 3 of the flow above.
When workspace is provisioned, the TRE Admin passes the secret name as a parameter.
Resource Processor, when the bundle action is executed, fetches the secret value from Core Keyvault, and passes it in in "credentials" parameters of Porter (this will need verifying).

Advantages:

• No additional keyvault is created

Disadvantages:

• Rotation of secrets needs to be solved: it's not enough to simply update value of the secret, the user resources depending on the secret value need to also be manually updated.

Option 2: New keyvault ("Shared keyvault")

In this option, Azure Contributor puts the secret into a specially created Keyvault in step 3 of the flow above.
This keyvault needs to be created in the Shared subnet, so that workspaces have access to it.
When workspace is provisioned, the TRE Admin passes the secret name as a parameter. This secret can then be referenced directly from the Shared keyvault by the user resources (e.g. Guacamole), importing it as a data attribute.

Advantages:

• Rotation of secrets works out-of-the-box: when secret is updated in the Shared Keyvault, the resources, referencing the secret via resource_versionless_id, should always get the updated value (this will need verifying).

Disadvantages:

• Maybe it's a bit odd to create a keyvault to just put one or a few secrets in it

Acceptance criteria

• Implement chosen approach
• Update docs on how the workpsace secret needs to be stored
• Revert changes from Redact secrets before saving resources in Cosmos #2066 (as we won't have any sensitive values in Cosmos anymore)

[marrobi]

Got a potential alternate approach for this. Admin created the App Registration. Makes Application Admin the owner, when workspace deploys its imported into terraform and the configuration (update and secret creation) is done as it is done with automatic app registration.