Google Cloud Private Service Connect and Snowflake¶

Overview¶

Google Cloud Private Service Connect provides private connectivity to Snowflake by ensuring that access to Snowflake is through a private IP address. Snowflake appears as a resource in your network (i.e. customer network), but the traffic flows one-way from the your VPC to Snowflake VPC over the Google networking backbone. This setup significantly simplifies the network configuration while providing secure and private communication.

The following diagram summarizes the Google Cloud Private Service Connect architecture with respect to the customer Google Cloud VPC and the Snowflake service.

The Google Compute Engine (i.e. a virtual machine) connects to a private, virtual IP address which routes to a forwarding rule (1). The forwarding rule connects to the service attachment through a private connection (2). The connection is routed through a load balancer (3) that redirects to Snowflake (4).

Configuration procedure¶

This section describes how to configure Google Cloud Private Service Connect to connect to Snowflake.

1. Contact Snowflake Support and provide a list of your Google Cloud <project_id> values and the corresponding URLs that you use to access Snowflake with a note to enable Google Cloud Private Service Connect. After receiving a response from Snowflake Support, continue to the next step.

   Important

   If you are using VPC Service Controls in your VPC, ensure that the policy allows access to the Snowflake service before contacting Snowflake Support.

   If this action is not taken, Snowflake will not be able to add your project ID to the Snowflake service attachment allow list. The result is that you will be blocked from being able to connect to Snowflake using this feature.

2. In a Snowflake worksheet, run the SYSTEM$GET_PRIVATELINK_CONFIG function with the ACCOUNTADMIN system role, and save the command output for use in the following steps:

   use role accountadmin;
   select key, value from table(flatten(input=>parse_json(system$get_privatelink_config())));
   

   Copy

3. In a command line interface (e.g. the Terminal application), update the gcloud library to the latest version:

   gcloud components update
   

   Copy

4. Authenticate to Google Cloud Platform using the following command:

   gcloud auth login
   

   Copy

5. In your Google Cloud VPC, set the project ID in which the forwarding rule should reside.

   gcloud config set project <project_id>
   

   Copy

   To obtain a list of project IDs, execute the following command:

   gcloud projects list --sort-by=projectId
   

   Copy

6. In your Google Cloud VPC, create a virtual IP address:

   gcloud compute addresses create <customer_vip_name> \
   --subnet=<subnet_name> \
   --addresses=<customer_vip_address>
   --region=<region>
   

   Copy

   For example:

   gcloud compute addresses create psc-vip-1 \
   --subnet=psc-subnet \
   --addresses=192.168.3.3 \
   --region=us-central1
   
   # returns
   
   Created [https://www.googleapis.com/compute/v1/projects/docstest-123456/regions/us-central1/addresses/psc-vip-1].
   

   Copy

   Where:

   • <customer_vip_name> specifies the name of the virtual IP rule (i.e. psc-vip-1).

   • <subnet_name> specifies the name of the subnet.

   • <customer_vip_address>: all private connectivity URLs resolve to this address. Specify an IP address from your network or use CIDR notation to specify a range of IP addresses.

   • <region> specifies the cloud region where your Snowflake account is located.

   .

7. Create a forwarding rule to have your subnet route to the Private Service Connect endpoint and then to the Snowflake service endpoint:

   gcloud compute forwarding-rules create <name> \
   --region=<region> \
   --network=<network_name> \
   --address=<customer_vip_name> \
   --target-service-attachment=<privatelink-gcp-service-attachment>
   

   Copy

   For example:

   gcloud compute forwarding-rules create test-psc-rule \
   --region=us-central1 \
   --network=psc-vpc \
   --address=psc-vip-1 \
   --target-service-attachment=projects/us-central1-deployment1-c8cc/regions/us-central1/serviceAttachments/snowflake-us-central1-psc
   
   # returns
   
   Created [https://www.googleapis.com/compute/projects/mdlearning-293607/regions/us-central1/forwardingRules/test-psc-rule].
   

   Copy

   Where:

   • <name> specifies the name of the forwarding rule.

   • <region> specifies the cloud region where your Snowflake account is located.

   • <network_name> specifies the name of the network for this forwarding rule.

   • <customer_vip_name> specifies the <name> value (i.e. psc-vip-1) of the virtual IP address created in the previous step.

   • <privatelink-gcp-service-attachment> specifies the endpoint for the Snowflake service (see step 2).

   .

8. Use the following command to verify the forwarding-rule was created successfully:

   gcloud compute forwarding-rules list --regions=<region>
   

   Copy

   The cloud region in this command must match the cloud region where your Snowflake account is located.

   For example, if your Snowflake account is located in the europe-west-2 region, replace <region> with europe-west2.

   For a complete list of Google Cloud regions and their formatting, see Viewing a list of available regions.

9. Update your DNS settings.

   All requests to Snowflake need to be routed through the Private Service Connect endpoint so that the URLs in step 2 (from the SYSTEM$GET_PRIVATELINK_CONFIG function) resolve to the VIP address that you created (<customer_vip_address>).

   These endpoint values allow you to access Snowflake, Snowsight, and the Snowflake Marketplace while also using OCSP to determine whether a certificate is revoked when Snowflake clients attempt to connect to an endpoint through HTTPS and connection URLs.

   The values to obtain from the $SYSTEM_GET_PRIVATELINK_CONFIG function are:

   • privatelink-account-url

   • privatelink-connection-ocsp-urls

   • privatelink-connection-urls

   • privatelink-ocsp-url

   • regionless-privatelink-account-url

   • regionless-snowsight-privatelink-url

   • snowsight-privatelink-url

   Note that the values for regionless-snowsight-privatelink-url and snowsight-privatelink-url allow access to Snowsight and the Snowflake Marketplace using private connectivity. However, there is additional configuration if you want to enable URL redirects.

   For details, see Snowsight & Private Connectivity.

   Note

   A full explanation of DNS configuration is beyond the scope of this procedure. For example, you can choose to integrate a private DNS zone into your environment using Cloud DNS. Please consult your internal Google Cloud and cloud infrastructure administrators to configure and resolve the URLs in DNS properly.

10. Test your connection to Snowflake using SnowCD (Connectivity Diagnostic Tool).

11. Connect to Snowflake with your private connectivity account URL.

    Note that if you want to connect to Snowsight via Google Cloud Private Service Connect, follow the instructions in the Snowsight documentation.

Using SSO with Google Private Service Connect¶

Snowflake supports using SSO with Google Cloud Private Service Connect. For more information, see:

• SSO with private connectivity

• Partner applications

Using Client Redirect with Google Cloud Private Service Connect¶

Snowflake supports using Client Redirect with Google Cloud Private Service Connect.

For more information, see Redirecting client connections.

Using Replication & Tri-Secret Secure with Private Connectivity¶

Snowflake supports replicating your data from the source account to the target account, regardless of whether you enable Tri-Secret Secure or this feature in the target account.

Blocking public Access — Recommended¶

After testing the Google Cloud Private Service Connect connectivity with Snowflake, you can optionally block public access to Snowflake using Controlling network traffic with network policies.

Configure the CIDR block range to block public access to Snowflake using your organization’s IP address range. This range can be from within your virtual network.

Once the CIDR Block ranges are set, only IP addresses within the CIDR block range can access Snowflake.

To block public access using a network policy:

1. Create a new network policy or edit an existing network policy. Add the CIDR block range for your organization.

2. Activate the network policy for your account.