The networking capabilities of Azure SQL Database have been evolving since its inception, as the service offering became more diverse and the underlying infrastructure platform matured. The initial constraints that limited connectivity to an external, publicly accessible endpoint have been eliminated with the introduction of such technologies as Service Endpoints and Azure Private Link. In this article, you will learn about the range of connectivity options available for Azure SQL Database deployments.
The original implementation of Azure SQL Database exposed a public endpoint with a dynamically assigned IP address (associated with a fully qualified domain name of the logical database server) and the standard TCP port 1433 (matching the one assigned to the default instance of the traditional database engine installation). Azure SQL Database could not be deployed directly into an Azure virtual network, so it was lacking a private IP address. Effectively, any communication (including requests originating from Azure VMs) was routed via that public endpoint. While such communication was a subject to authentication and authorization constraints on the logical server and the database level, it was viewed by many customers as potential vulnerability, blocking or delaying service adoption.
One potential remediation method relied on service-side firewall (available on both the logical server- and the database- level), allowing restricting inbound traffic based on the source IP addresses, but such approach led to increased management overhead and was not always feasible (e.g. in scenarios where source IP addresses could not be reliably determined ahead of time).
To address these challenges, Microsoft diversified the service offering by introducing Azure SQL Database Managed Instance. While its biggest selling point was close-to-full parity from the functionality standpoint (practically eliminating potential compatibility issues when migrating on-premises databases), it also implemented considerably different networking model. Managed Instance is provisioned into a dedicated subnet of a virtual network and gets assigned a private IP address within the IP address range of that subnet (interestingly, this private IP address is associated with a fully qualified domain name that is publicly resolvable). This makes possible to connect to it directly from the same Azure virtual network, any other Azure virtual network connected through VNet peering or VNet-to-VNet, as well as from on-premises locations via ExpressRoute or Site-to-Site VPN, without having to cross public Internet.
Managed Instance also supports public endpoints (via TCP port 3342), allowing customers to provide external connectivity. Their implementation is a two-step process. The first one consists of enabling this feature (which can be accomplished directly from the Azure portal). The second step involves modifying the Network Security Group associated with the subnet hosting the managed instance, by adding a rule allowing explicitly incoming traffic over TCP port 3342 and overriding the deny_all_inbound rule.
It is worth noting that Managed Instance relies heavily on outbound connectivity to other Azure services (including Azure Key Vault for Transparent Data Encryption, Azure Storage for backups, Azure Event Hubs for telemetry, and Azure AD for authentication). At the same time, it relies on so called management endpoints to allow inbound management plane connections from the Azure fabric. While both communication paths traverse the same management endpoint IP address, such endpoint is not used for data plane and, additionally, is protected via built-in service firewall and mutual certificate-based authentication. The resulting networking configuration is relatively complex, however all necessary configuration settings (including Network Security Groups and User Defined Routes) are set up automatically as part of service provisioning (with exception of the public endpoint, which configuration is customers' responsibility).
Obviously the networking capabilities of Managed Instance have not provided any consolation to existing Azure SQL Database customers. The remediation came in the form of Service Endpoints, which, once implemented, directed traffic originating from virtual networks to public endpoints via Azure backbone (Service Endpoints are available for a range of Azure Platform-As-a-Service, including Azure SQL Database). By combining this functionality with logical server-level firewall (potentially further supplemented by database-level firewall), it became possible to fully block traffic coming from Internet and allow connections from designated virtual network subnets only.
Unfortunately Service Endpoints still have a couple of important limitations. The first one results from lack of granularity when designating the target endpoints, restricting connections to a regional service (e.g. Azure SQL Database in East US), rather than a specific service instance (Service Endpoint Policies promise to provide this functionality, but they have been in public preview for more than a year). The second one ties to the configuration of the source of the connections, which must correspond to Azure virtual network subnets. This, in turn, eliminates the possibility of using service endpoints when connecting from on-premises locations via Site-to-Site VPN or ExpressRoute.
Both limitations are resolved in a recent Azure offering named Private Link. Its main benefits include the support for a private IP address assignment (and the corresponding DNS name) to an instance of an Azure PaaS service (such as Azure SQL Database). Such configuration makes possible to limit network connections to that instance only and to make it accessible from locations outside of Azure that have direct connectivity to the virtual network from which the private IP address has been allocated (such as on-premises locations connected via ExpressRoute or Site-to-Site VPN). The service target can reside in any Azure region and can be part of any Azure subscription. Just as with service endpoints, traffic is routed via Azure backbone, without crossing public Internet. It remains to be seen how soon Private Link will become generally available, but it promises to resolve current Azure SQL Database networking challenges.
The original implementation of Azure SQL Database exposed a public endpoint with a dynamically assigned IP address (associated with a fully qualified domain name of the logical database server) and the standard TCP port 1433 (matching the one assigned to the default instance of the traditional database engine installation). Azure SQL Database could not be deployed directly into an Azure virtual network, so it was lacking a private IP address. Effectively, any communication (including requests originating from Azure VMs) was routed via that public endpoint. While such communication was a subject to authentication and authorization constraints on the logical server and the database level, it was viewed by many customers as potential vulnerability, blocking or delaying service adoption.
One potential remediation method relied on service-side firewall (available on both the logical server- and the database- level), allowing restricting inbound traffic based on the source IP addresses, but such approach led to increased management overhead and was not always feasible (e.g. in scenarios where source IP addresses could not be reliably determined ahead of time).
To address these challenges, Microsoft diversified the service offering by introducing Azure SQL Database Managed Instance. While its biggest selling point was close-to-full parity from the functionality standpoint (practically eliminating potential compatibility issues when migrating on-premises databases), it also implemented considerably different networking model. Managed Instance is provisioned into a dedicated subnet of a virtual network and gets assigned a private IP address within the IP address range of that subnet (interestingly, this private IP address is associated with a fully qualified domain name that is publicly resolvable). This makes possible to connect to it directly from the same Azure virtual network, any other Azure virtual network connected through VNet peering or VNet-to-VNet, as well as from on-premises locations via ExpressRoute or Site-to-Site VPN, without having to cross public Internet.
Managed Instance also supports public endpoints (via TCP port 3342), allowing customers to provide external connectivity. Their implementation is a two-step process. The first one consists of enabling this feature (which can be accomplished directly from the Azure portal). The second step involves modifying the Network Security Group associated with the subnet hosting the managed instance, by adding a rule allowing explicitly incoming traffic over TCP port 3342 and overriding the deny_all_inbound rule.
It is worth noting that Managed Instance relies heavily on outbound connectivity to other Azure services (including Azure Key Vault for Transparent Data Encryption, Azure Storage for backups, Azure Event Hubs for telemetry, and Azure AD for authentication). At the same time, it relies on so called management endpoints to allow inbound management plane connections from the Azure fabric. While both communication paths traverse the same management endpoint IP address, such endpoint is not used for data plane and, additionally, is protected via built-in service firewall and mutual certificate-based authentication. The resulting networking configuration is relatively complex, however all necessary configuration settings (including Network Security Groups and User Defined Routes) are set up automatically as part of service provisioning (with exception of the public endpoint, which configuration is customers' responsibility).
Obviously the networking capabilities of Managed Instance have not provided any consolation to existing Azure SQL Database customers. The remediation came in the form of Service Endpoints, which, once implemented, directed traffic originating from virtual networks to public endpoints via Azure backbone (Service Endpoints are available for a range of Azure Platform-As-a-Service, including Azure SQL Database). By combining this functionality with logical server-level firewall (potentially further supplemented by database-level firewall), it became possible to fully block traffic coming from Internet and allow connections from designated virtual network subnets only.
Unfortunately Service Endpoints still have a couple of important limitations. The first one results from lack of granularity when designating the target endpoints, restricting connections to a regional service (e.g. Azure SQL Database in East US), rather than a specific service instance (Service Endpoint Policies promise to provide this functionality, but they have been in public preview for more than a year). The second one ties to the configuration of the source of the connections, which must correspond to Azure virtual network subnets. This, in turn, eliminates the possibility of using service endpoints when connecting from on-premises locations via Site-to-Site VPN or ExpressRoute.
Both limitations are resolved in a recent Azure offering named Private Link. Its main benefits include the support for a private IP address assignment (and the corresponding DNS name) to an instance of an Azure PaaS service (such as Azure SQL Database). Such configuration makes possible to limit network connections to that instance only and to make it accessible from locations outside of Azure that have direct connectivity to the virtual network from which the private IP address has been allocated (such as on-premises locations connected via ExpressRoute or Site-to-Site VPN). The service target can reside in any Azure region and can be part of any Azure subscription. Just as with service endpoints, traffic is routed via Azure backbone, without crossing public Internet. It remains to be seen how soon Private Link will become generally available, but it promises to resolve current Azure SQL Database networking challenges.
Posts
0 comments:
Post a Comment