Sev1: a Snowflake network policy locked out every user and integration

#Symptoms

• Logins fail with: IP address x.x.x.x is not allowed to access Snowflake. Contact your local security administrator. (error 390432 or similar).
• BI dashboards, dbt jobs, Airflow tasks and connectors all fail at the same time.
• It started right after someone ran ALTER ACCOUNT SET NETWORK_POLICY = ... or changed an allowed IP list or network rule.

#Step 1: who still has access? (5 minutes)

A network policy can be set at account level, user level, or on security integrations. A user-level policy overrides the account-level policy. So:

• Any user with a user-level policy that allows your current IP can still log in.
• Admins sometimes keep a break-glass user with its own permissive (or office-only) policy exactly for this.

Try the break-glass user from the allowed location. If none exists, try from a network that is in the new policy's allowed list (office VPN, a jump host, the egress IP of a pipeline that is listed).

Find your current public egress IP to compare with the policy:

curl -s https://checkip.amazonaws.com

#Step 2: unset or fix the account policy

Once in, with a role that owns the policy or has the account privilege to attach policies (SECURITYADMIN or ACCOUNTADMIN):

USE ROLE SECURITYADMIN;
SHOW PARAMETERS LIKE 'NETWORK_POLICY' IN ACCOUNT;
DESCRIBE NETWORK POLICY corp_policy;

Fastest relief, remove the account-level policy:

ALTER ACCOUNT UNSET NETWORK_POLICY;

Or fix the list (legacy IP list style):

ALTER NETWORK POLICY corp_policy SET ALLOWED_IP_LIST = ('203.0.113.0/24', '198.51.100.17/32');

Or with network rules:

DESCRIBE NETWORK RULE security.rules.corp_ingress;
ALTER NETWORK RULE security.rules.corp_ingress SET VALUE_LIST = ('203.0.113.0/24', '198.51.100.17/32');

Changes apply to new logins immediately.

Warning

Unsetting the policy reopens access from any IP. It is the right emergency move only if MFA/SSO is enforced. Fix the allowed list and re-apply as soon as service is restored.

#Step 3: no one can log in at all

If no user has a user-level exception and no allowed network is reachable, contact Snowflake Support through the support portal (from an account that can open cases, or through your account team). They can help restore access after verifying ownership. Have ready: account locator, organisation name, the time of the change, and the IP ranges you need.

This is why step 1 of "prevent it next time" matters.

#Step 4: find what each integration needs

Collect egress IPs before re-applying a strict policy:

See who logged in from where in the last week, to avoid forgetting a client:

SELECT client_ip, user_name, reported_client_type, COUNT(*) AS logins, MAX(event_timestamp) AS last_seen
FROM snowflake.account_usage.login_history
WHERE event_timestamp > DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND is_success = 'YES'
GROUP BY 1, 2, 3
ORDER BY logins DESC;

Failed logins blocked by the policy:

SELECT client_ip, user_name, error_message, COUNT(*)
FROM snowflake.account_usage.login_history
WHERE event_timestamp > DATEADD(hour, -6, CURRENT_TIMESTAMP()) AND is_success = 'NO'
GROUP BY 1, 2, 3 ORDER BY 4 DESC;

LOGIN_HISTORY in account usage lags; INFORMATION_SCHEMA.LOGIN_HISTORY() table function is closer to real time.

#Step 5: re-apply safely

1. Build the policy with all ranges from step 4.
2. Test it on one user first:

ALTER USER test_netpolicy SET NETWORK_POLICY = corp_policy;

3. Log in as that user from each client type. Then apply to service users one at a time.
4. Only then apply at account level, during working hours, with a second admin on a different network ready.

ALTER ACCOUNT SET NETWORK_POLICY = corp_policy;

#Step 6: confirm

• Users, BI, and pipelines log in; failed logins with the IP error drop to zero (except genuinely unwanted sources).
• Break-glass user tested and documented.

#Prevent it next time

• Keep a break-glass admin user with its own user-level policy allowing a tightly controlled network (for example a secured admin jump host), with MFA, stored in your vault.
• Every network policy change goes through a reviewed script that tests on a user first.
• Monitor LOGIN_HISTORY for spikes in failed logins with IP errors and alert.
• Use network rules with private connectivity identifiers for pipelines, so IP changes at vendors do not break you.