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:
- TCP/1433 over Internet:
- Pro: Easiest solution
- Con:
- Security teams have each time refused this.
- Query Editor in the Portal:
- Pro: Integrated in the Portal
- Con:
- Reduced feature set compared to SSMS
- Traffic is also initiated on port 1433
- Go for Managed Instances
- Pro:
- Azure SQL available on private IP address, no hassle with outbound connectivity
- Con:
- High consumption costs
- Microsoft Peering on the ExpressRoute
- Pro:
- No outbound connectivity
- Con:
- Challenging to get this properly configured (Express Route, ISP, Route Filters, BGP announcements, etc.)
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.
- Large list of available base images that can be customized with formulas (SKU, VNET, Private IP, etc.)
- Artifacts can be used to install developer tools (Git, Visual Studio Code, SQL Server Management Studio, etc.)
- Machine Auto-Start and Auto-Stop Integrated (What is turned off is less vulnerable)
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.