Customers trust Snowflake Cloud Data Platform with their most sensitive data. To earn that trust, Snowflake uses a multilayered security approach (network, identity and access management [IAM], and data encryption) to protect customer data. Network security, also known as perimeter security, provides the first line of defense against bad actors trying to access Snowflake customer accounts. To safeguard against bad actors, Snowflake offers two types of controls for network security: private connectivity and using network policies to allow known IP ranges to connect to Snowflake.
We’re happy to announce the general availability of the Azure Private Link integration for Snowflake customers who use Azure to facilitate private connectivity to Snowflake. With this integration, Snowflake accounts are accessible over private IP addresses from a customer’s network similar to other applications running on their network, while keeping the data flow private on Microsoft Azure’s secure network. The data never traverses the public internet, which significantly reduces exposure to common security threats. In addition to enhancing the security posture, the Azure Private Link integration simplifies the network topology.
The Azure Private Link integration provides the following benefits:
- Enables private access to Snowflake: Customers can connect their virtual networks (VNets) to Snowflake in a secure and scalable manner.
- The Snowflake account appears as a private IP address in the customer’s VNet.
- Traffic remains on Microsoft Azure’s secure network.
- There is one-way connectivity from the VNet to Snowflake.
- Works with on-premises and peered networks: Customers can access their Snowflake account over private peering/VPN tunnels (from on-premises systems) and also from peered virtual networks.
How does it work?
Snowflake on Azure exposes the Private Link service endpoint. Customers connect to the Service endpoint from a Private endpoint in their VNet. The following diagram summarizes the one-time configuration in Snowflake and Microsoft Azure. You can find detailed instructions in the documentation.
Once the setup is complete, you can connect to Snowflake over Azure Private Link from any client application running on premises or in your VNet or you can connect through the Snowflake UI.
How do I connect to Snowflake from multiple VNets within the same region or across regions?
You can set up a hub-and-spoke network topology where one VNet is used to connect to Snowflake in the same region. The rest of the VNets in the same region or across regions are peered to this hub VNet.
How do I connect from VNets that belong to different Azure Active Directory tenants?
You can connect to Snowflake from VNets that belong to different Azure AD tenants by iterating over the setup process for each of your Azure AD tenant VNets.
What URLs do I need to resolve through DNS to the private endpoint?
Snowflake doesn’t support vanity URLs, and you must to set up DNS resolution for these two URLs:
How do I set up DNS to resolve the Snowflake private link URLs?
As a best practice, you can use the Azure Private DNS zone (or a custom DNS server) in your VNet to resolve Snowflake URLs. If you want to access Snowflake from an on-premises network, you can set up DNS forward rules for *.privatelink.snowflakecomputing.com in your on-premises DNS. If your network team needs the full URL instead of using the wildcard URL, you can obtain it by running the system function SYSTEM$WHITELIST_PRIVATELINK() in Snowflake.
How do I block public endpoint access once Azure Private Link is setup?
To block public endpoint access to your Snowflake account, set up a network policy in Snowflake and add your private network IP range to the allowed list. The client IP address is propagated by Azure Private Link to Snowflake using the TCP proxy protocol v2 (PPv2).
Can third-party tools running outside of the customer network connect to Snowflake over Azure Private Link?
No. Because Azure Private Link connectivity is locked down from your VNet to the Snowflake VNet, you can’t use third-party tools such as Power BI Service, Fivetran, and others that are running outside of your network. If you need to use these tools, use the Snowflake public endpoint with these tools. You can use a Snowflake user-level network policy for opening up limited access to Snowflake instead of whitelisting the third-party tool outbound IP ranges in the account-level network policy.