Establish a way to authenticate to the API from a porter bundle

Requirements

Allow the porter bundle itself to call the TRE API and submit PATCH requests.

Design Proposed A

In order for the Porter Bundle to be able to authenticate against the API it will require a CLIENT_ID and CLIENT SECRET for the API and probably the workspace. We currently create a TEST_ACCOUNT and grant this permission for E2E and development flows. I propose we rename this account and use it for porter bundles to interact with the API and for running the tests.

All of the AAD assets will be setup by running make auth and we will remove the optional --automation-account switch so that this application is always created when we create the TRE API AAD Application. The ClientId/Secret will be copied into the .env file and CI/CD secrets respectively. The values will be copied into KeyVault when Terraform runs and the Resource Processor (using MSI) will read the secrets and use them to communicate with the API at runtime.

The Tests will be changed to use this same account to be able to interact with the API from outside the Resource Processor

• Remove optional --automation-account from AAD script
• Rename TEST_ACCOUNT_CLIENT_ID and TEST_ACCOUNT_CLIENT_SECRET to API_ADMIN_CLIENT_ID, etc
• Add API_ADMIN_CLIENT_* to KeyVault at creation time #1634
• Retrieve secrets from KV within the Resource processor #1634
• Call bash script (maybe python later if time permits to change container) to PATCH API
• Fix up all the tests

Design Proposed B

In order for the Porter Bundle to be able to authenticate against the API it will require a CLIENT_ID and CLIENT SECRET as auth is in a different tenant than the Resource Processor. A Manual process (which we already have) creates an AAD Application with TREAdministrator and Application.ReadWriteAll. These client id/secret are passed in via .env/ or GH secrets and are placed in the core KeyVault. When a Workspace bundle installer is run, it retrieves this secret and uses it to create an AppRegistration called Workflow1 via Terraform. This is a different Terraform login to the one that creates Azure infrastructure. The newly created SPN is returned and used to trigger the existing Workflow bundle which creates the Azure Workflow infrastructure. It then places this new SPN creds in the Workflow KeyVault. Thus solving

• no need to pass in the workspace app id in the body of requests anymore as porter can retrieve it from key vault.
• if one workspace needs to update another workspace resource it uses the spn to communicate with the API (and doesn’t use the SPN that has ReadWrite.All perms)

Downside, using the workflow spn means it will not be able to authenticate against the tre api; only the workspace api

Alternative Considered

Use the User Managed System Identity for Azure that the Virtual Machine Scale Set runs as. This has Owner permissions on the subscription. Could it be used to make requests of the API?

No. A MSI exists in the tenant that owns the Azure subscription and in some deployments we are using a different tenant to authenticate. A MSI cannot be granted permission to another tenant. https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identities-faq#can-i-use-a-managed-identity-to-access-a-resource-in-a-different-directorytenant

[damoodamoo]

Yep - makes sense to me. The resource processor is just a client of the API at this point, regardless of where it’s deployed. ID + secret/cert is the only way to authenticate.

[martinpeck]

Closing this as we have taken a different approach.