Route Guacamole traffic through the app gateway

[jonnyry]

Route Guacamole traffic through the App Gateway, and do not allow direct connections to guacamole service endpoints.

This would provide the following benefits:

• TRE web traffic would flow through a single ingress point
• a single trusted domain name can be used, rather than relying on default azure domain names for guacamole
• App Gateway WAF features can be enabled for all web traffic rather than just API + UI
• would meet Apache’s recommendation of hosting behind a reverse proxy: https://guacamole.apache.org/doc/gug/reverse-proxy.html

[jonnyry]

This PR resolves the issue however wasn’t merged as it introduced a 100 workspace limit (due to App Gateway max 100 backend pool limit):

#3731

Wondering whether a shared Guacamole service might be a plausible solution instead, rather than 1 per workspace - though are there downsides to this approach?

[marrobi]

The reason we did it independently was to minimise the work needed to handle auth for each workspace. The shared service would be an ok solution from my perspective, as long as tokens are validated against the appropriate workspace application ID. At the moment we use OAuth Proxy - https://github.com/oauth2-proxy/oauth2-proxy. In addition the custom authentication extension (java) access the KeyVault in the workspace to retrieve the credentials for the VM.

So it's not straight forward, but if want to put a design proposal together, and are willing to put in the time to do a PR once aligned, then we can discuss it.

[jonnyry]

OK thanks for the info, still considering options at the moment.

Another potential could be to change the App Gateway for Azure Front Door, which if I have read the docs correctly, supports a greater number of backend pools/origins: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-front-door-standard-and-premium-service-limits (Azure FD does not support websocket connections)

[marrobi]

See #3731