Use custom DNS addresses when accessing internal resources from the external world (like guacamole) #3731
Conversation
tamirkamara
force-pushed
the
tamirkamara/guacamole-appgw
branch
from
3a7dda2
to
570eca9
Compare
| - exec: | ||
| command: bash | ||
| arguments: | ||
| - ./import.sh |
There was a problem hiding this comment.
But of an aside, but could we do this with the firewall shared service? I was actually thinking about this this week, will this affect the RP prior to the Firewall being deployed: https://azure.microsoft.com/en-gb/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/
There was a problem hiding this comment.
About the firewall, do you mean install it in core and then import when the shared service is installed?
I'd feel more comfortable with doing the import with terraform 1.5 rather than the script I have now.
There was a problem hiding this comment.
Yes, from what I understand in that blog post, and VMs in core won't have internet access until the firewall is deployed.
What is stopping us moving to 1.5?
There was a problem hiding this comment.
That vm change is 1-2 years away so maybe not pressing to tend to.
Upgrade to 1.5 (or 1.6 as it's released already) would require testing everything. Not a major thing but still. We'll also need to verify the new license.
tamirkamara
force-pushed
the
tamirkamara/guacamole-appgw
branch
from
570eca9
to
1f7a985
Compare
|
Tested this today and seemed to work well. Going to do a bit more digging and will review properly. |
|
I've come back to this, and been having a look at Entra ID application proxy.. https://learn.microsoft.com/en-us/entra/identity/app-proxy/what-is-application-proxy Got it working.
Need to consider the two options. |
How is the Application Proxy URL better than the native App Service URL? |
SvenAelterman
changed the title
That's a good question :), I was thinking about having a corporate domain with single SSL, it also means we are using a managed authentication solution, rather than relying on a 3rd party OSS component. |
Would it be TRE's responsibility to set that up though? Or would the customer make the decision to set up Application Proxy and configure a custom domain, etc.? |
|
The thing triggered me in at app proxy was the fact app gw limits to 100 back ends or rules so isn't as scalable as we might need. It also potentially avoids the need for an app gw shared service. Is a wider discussion here around what's the issue we are trying to resolve. |
|
In order to get around the max 100 backend pools, could Guacamole be promoted to a shared service? |
|
@tamirkamara just to confirm, this has TF that modifies the same App GW in two places? But ignores changes on the backend pool. Might be cleaner to have one app gw for core, and one in shared for shared and workspace services? The core one remains static. For the 100 backend pool limit, could we potentially deploy and app gw per 100 rules, and do 1-100 on one, 101-199 on the next etc. The rules per app gw could be configurable as might be we get to 50 and realise we need another? @jonnyry welcome your thoughts on this, as know is top of mind. |
|
Hi @marrobi That sounds like plan to overcome the 100 backend limit. In terms of the relationship between the two App Gateway, were you thinking something like below with one being nested behind the other? (Nb. the /guac0-99 etc URL paths on the first AGW are just as an example)
|
|
That probably makes most sense. Would welcome @tamirkamara's thoughts. We might also look at putting the airlock storage behind the core app gw. Would be interesting to think about how shared services, like Nexus could sit behind it too. |
|
I understand how this can overcome the 100 routes limit. Not sure I see how does it separate the need to make changes in the core's appgw... i.e. how does the guac0-99 route gets created? |
Yes, you are right, missed that. We need to have a think. |
Ah yes I missed this also. Few ideas - 1. Add an extra app gatway into the Guac-specific App Gateway Shared Service:(though not sure how I feel about three tiers of App Gateways)
2. Bring the core app gateway into the App Gateway Shared Service:
3. Switch out the Guac shared App Gateway for NGINXAAS and use that insteadPretty sure it doesn't have a hard backend limit. |
What is being addressed
When we access TRE resources from the external world we use their own DNS names which looks odd - it includes many random parts that might be recognized as risky sites by users and browser protection schemes.
A prime example for this is the Guacamole workspace service which is accessed from the internet by its own app-service URL.
How is this addressed
The
installaction simply imports its current configuration to the state since it's installed in the core section.