Network Policies

If your Snowflake account has an active network policy, you may encounter issues with the Posit Team Native App during the OAuth flow or while running Snowflake SQL queries from within Workbench sessions or Connect using the Snowflake integration. For more details on activating a network policy for your account, refer to Snowflake’s network policies documentation.

You can easily check if a network policy is active in your account using the given SQL.

SHOW PARAMETERS LIKE '%NETWORK_POLICY%' IN ACCOUNT;

Common Errors

You will often see errors in the following forms:

  1. OAuth Flow Error in Workbench or Connect

Error messages:

Error 100: Error occurred while executing method.
Error 230: {"code":230,"error":"invalid_client","payload":""}

These errors typically occur during the Workbench managed credential OAuth flow.

  1. SQL Query Error:

Error message:

Incoming request with IP/Token aaa.bbb.ccc.ddd is not allowed to access Snowflake. Contact your account administrator.

Occurs when executing SQL queries via R, Python, or a CLI in the Native App.

These errors occur because Snowflake does not trust the public IPs originating from Snowflake SPCS services (e.g., Workbench Native App). To resolve this, you need to whitelist the public IPs associated with your Workbench deployment.

Resolution Steps

Step 1: Obtain the Public IPs

You can identify the public IPs of your Workbench deployment by running one of the following scripts. This example uses checkip.amazonaws.com, a trusted service, to fetch the IP addresses. Ensure that your egress policy allows traffic to checkip.amazonaws.com:443.

Python Console
import requests
ips = {
    requests.get('https://checkip.amazonaws.com').text.strip()
    for _ in range(20)
}
print('\n'.join(ips))
R Console
library(httr2)

ips <- replicate(20, {
  req <- request("https://checkip.amazonaws.com/")
  resp <- req_perform(req)
  trimws(resp_body_string(resp))
})

cat(unique(ips), sep="\n")
Terminal
for i in {1..20}; do
    curl -s https://checkip.amazonaws.com
done | sort -u

This process typically returns three IPs, but repeat the commands if necessary to ensure all IPs are captured.

Step 2: Update the Network Policy

Once you have the public IPs, add them to the ALLOWED_NETWORK_RULE_LIST of your Snowflake account’s active network policy. This change will allow the Workbench Native App to authenticate and execute queries successfully.

Example SQL to update the network policy:

Snowsight UI
CREATE OR REPLACE NETWORK RULE POSIT_TEAM_PUBLIC_IPS
  TYPE = IPV4
  VALUE_LIST = ('new_workbench_ip_1', 'new_workbench_ip_2', 'new_workbench_ip_3')
  MODE = INGRESS
  COMMENT = 'Posit Team public egress IPs';
  
ALTER NETWORK POLICY your_network_policy_name ADD ALLOWED_NETWORK_RULE_LIST = 'POSIT_TEAM_PUBLIC_IPS';
DESC NETWORK POLICY your_network_policy_name;

Changes to the network policy take effect within five seconds. You should see OAuth flows and SQL queries resolve immediately.

Additional Notes

Public IP Changes

Snowflake may occasionally update the public IPs associated with SPCS services. While changes are infrequent, it’s a good practice to periodically verify and update the IP list to prevent disruptions. We are working with Snowflake to provide an official mechanism for retrieving these IPs.

Custom Egress Rules

If you are using custom egress policies, ensure that checkip.amazonaws.com:443 or an equivalent IP identification service is allowed.

Troubleshooting Tip

If errors persist, verify the updated network policy and ensure all relevant public IPs are included. You can also consult the Workbench logs for additional details.

Back to top