Aug 08 2019 09:02 AM
Introduction
Recently I have seen multiple enterprise customers struggling with the same issue which was how to give developers the right tools and connectivity to do their development work against Azure resources. Luckily, most of Azure services are reachable on HTTPS, which in most cases will be allowed and only a request to allow the URLS in the web proxy should be sufficient.
But what with the non-https connections like RDP, SSH, SQL, Redis, etc.? Most of the time, non-HTTPS outbound traffic is blocked by the corporate firewall. When you initiate the same connection from another location - outside the corporate network or your mobile phone - these connection will work without any issue. Of course, with the assumption IP ACLs and Service Endpoints are correctly configured on the Azure resources to accept the traffic from this location.
I have seen this very specific issue on how to allow TCP/1433 to an Azure SQL Database generating friction and frustrations for the developers, opening again the traditional discussions between the digital teams and infrastructure teams.
I considered several options to solve this problem, but each of them hade pro's and cons:
Azure Bastion in combination with DevTest Labs
With the announcement of the preview of Microsoft Azure Bastion, it's possible to create an seamless RDP and SSH session over HTTPS (TCP/443). As you can see, there is no real solution for traffic other than RDP and SSH, but we can use this Bastion host as in-between to access the Azure SQL from a developer virtual machine running in Azure.
The first feedback from customers is that there is again an IaaS component (DevTest Labs) present, which I fully can understand, but for now there is no alternative to give a developer a full SSMS console than hosting it on a VM. Managing golden images like they used to do is not something they have in their plan when adopting PaaS Services. I'm convinced Azure DevTest Labs is a good alternative.
In combination with the DevTest Labs, I have decided to configure a service endpoint on the subnet where the DevTest Lab VMS reside. In this way, only the machines running in this VNET will be able to access the Azure SQL. Another Service Endpoint can be created for subnets that need access too.
Additionally, an NSG can be applied on the AzureBastionSubnet where the access to the Bastion Host can be limited. In my case, I limited it to the IP addresses of the web proxy of the customer. This will cover connections from on-premise clients, clients connecting from home over VPN and any other traffic leaving the corporate proxy.
Setup:
I hope you find this solution helpful.