data-landing-zone
data-landing-zone copied to clipboard
Add Bastion deployment
Please add the option to deploy Bastion to the data-landing-zone templates. It was added to the data management zone portal deployment for Enterprise scale analytics (https://github.com/Azure/data-management-zone/commit/3ec03c8b4a1b8b3de21981c1a2c0951ad0f0d958)
Agreed. Azure Bastion would be very useful for connectivity to the deployment.
Thanks @baatch and @devlace. We are currently monitoring feedback and evaluate whether we should add this to the core setup. We will keep this issue open to track feedback.
I agree that Bastion is needed. Otherwise after deployment how will you connect ? Or did I miss something.
Hi @MiguelElGallo, We already have a template that is referenced here: https://github.com/Azure/data-management-zone/blob/main/docs/guidance/DataManagementAnalytics-ConnectToEnvironmentsPrivately.md
The question is whether we should add Bastion to the default Data Landing Zone deployment.
Alright, that is good enough Thanks!
I deployed the Bastion, with the "Deploy to Azure" button, in the document says:" 5. Once logged into the VM in a separate browser tab, go to Microsoft Edge and open Azure Portal. From here, navigate to the {prefix}-{environment}-product-synapse001 Synapse workspace inside the {prefix}-{environment}-shared-product resource group for data exploration." But the bastion cannot browse the internet, nor portal.azure.com. Is that point 5 correct? Thanks!
Hi @MiguelElGallo,
Have you changed anything on the network/firewall setup?
We have whitelisted *azure.com
in the firewall in order to allow you browsing to the Azure Portal. What URL are you trying to open?
Google is not whitelisted, but you should be able to directly open the page.
Hi, I was trying to open: dl2202-dev-product-synapse001.privatelink.dev.azuresynapse.net which should be the name of the Synapse Workspace. We did not deploy the Firewall, because we have one already. Still the bastion should be able to access Synapse Studio, but not sure if that is the URL I should be using. Any ideas? Thanks! Miguel
dl2202-dev-product-synapse001.privatelink.dev.azuresynapse.net
is just the API endpoint. You won't be able to do a "GET" on this endpoint.
The URL should look like this: https://web.azuresynapse.net/en-us/home?...
Alright, Thanks! Tried that! For some reason ,even I'm using the browser from the bastion, I still get: {"code":"PublicNetworkAccessDenied","message":"The public network interface on this Workspace is not accessible. To connect to this Workspace, use the Private Endpoint from inside your virtual network or enable public network access for this workspace."} Running out of ideas...
Can you run nslookup for the Synapse endpoints and check whether it resolves to the public IP or the private IP of the private endpoint?
e.g. nslookup dl2202-dev-product-synapse001.privatelink.dev.azuresynapse.net
This will show us whether the DNS resolution works as expected. If not, you may have forgotten to deploy the A-records/private DNS Zones Groups for the private endpoints.
Hi, You are right! The NSLookup returns public IP from my PC and from the Bastion. My question is now: What value should I put in parameter: dnsServerAdresses ? Private DNS zones work "automatic" with Virtual private networks, no need for DNS server. Thanks again, Cheers!
To which vnet are the Private DNS Zones linked? Is there a DNS forwarder/Azure Firewall hosted in that vnet?
Hi, As mentioned here: https://github.com/Azure/data-management-zone/issues/279 The landing zone guys, just provided us a VNET peered to the rest of the network. In that VNET there is NO DNS forwarder. Thanks
That is fine. Question is: Does your platform team provide any Private DNS Zones that you can use or do you have to create your own ones?
Can you please check any of the Synapse Private Endpoints and check whether it looks similar to the below:
Question is whether the DNS A-record is deployed in a Private DNS Zone in your or a central connectivity subscription:
Hi, We need to create our own zones. Yes Endpoints are fine, look like those. The thing is that the parameter DNSServer always sets a DNSServer, and that is not needed with vnets and private end points. We have commented that part that set DNS server and are doing some testing: Our first test was: DMLZ - Bastion inside, everything worked. now are deploying DLZ - Let'see Our request is anyways, that you should be able to deploy a DMLZ, without a firewall and a DNS set everywhere, for architectures like ours. Thanks!
Thanks for the feedback @MiguelElGallo. General guidance is to create a central DNS infrastructure for private endpoints inside an organizational tenant. Otherwise you or your organization will run into a management overhead when scaling within the tenant and when you require to resolve Private Endpoints across Azure Landing Zones.
The central network team should not only have a central Firewall, but also should provide a central DNS infrastructure that all Landing Zones can use. For pilots and PoCs we provide the option to also host this inside the Data Management Zone, but general guidance would be to host this in the connectivity hub of Azure Landing Zones. Therefore, we provide the option to either create a Firewall and DNS Zones in the Management Zone OR rely on the shared network infrastructure provided by the core Azure Platform team in the connectivity Hub.
I will take note of this feedback, but please also make sure that the implications of a decentralized DNS infrastructure in a tenant are well understood.
Thanks! I think that in both DMLZ and DLZ documentation like https://github.com/Azure/data-management-zone/blob/main/docs/DataManagementAnalytics-ServicePrincipal.md we need to have which roles does our SPN need, to be able to add stuff to the DNS, and with an explanation. Then it is easier to prove that we need that access. Because now our SPN can do whatever in our subscription, but a detailed list of roles needed for the SPN in the the connectivity hub of Azure Landing Zones would be really good. you think you can provide that ?
Hi @MiguelElGallo, Your platform team should optimally provide the following: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale#configuration-required-by-platform-team The policies mentioned in that article should be used to automate the setup of PrivateDnsZoneGroups. If the platform team does not use policies to automate this, they have to grant you and your Service Principal Private DNS Zone Contributor rights to do that. This is also documented here. Is that helpful?