Network Rules in Snowflake – Data/ML Engineer Blog

Network Rules in Snowflake: The Practical Guide for Data Engineers

Hook: Your security team wants outbound API calls from Snowflake to be locked to a few domains, while platform admins need tight inbound IP control for users and stages. If you’re still juggling ad-hoc IP lists in policies and integrations, you’re one mis-copy away from an incident. Snowflake’s network rules fix this by centralizing network identifiers once and reusing them everywhere. (Snowflake Docs)

Why this matters

Network rules are schema-level objects that group network identifiers (IPs, CIDRs, host:port, private endpoints). Features like network policies (inbound control) and external access integrations (outbound control) reference these rules instead of hardcoding addresses. Result: less duplication, cleaner reviews, safer changes. (Snowflake Docs)

Concepts & architecture (clear and simple)

Network Rule
A reusable object that lists network identifiers. It doesn’t decide allow/deny by itself—the consumer feature does. Modes:
- INGRESS / INTERNAL STAGE → used by network policies (inbound).
- EGRESS → used by external access integrations (outbound). (Snowflake Docs)
Network Policy (Inbound)
Controls who can connect to Snowflake services and, if enabled, internal stages. Policies reference INGRESS rules. Apply at account, user, or security integration level. (Snowflake Docs)
External Access Integration (Outbound)
Governs Snowflake-initiated egress for UDFs, procedures, Notebooks, Snowpark Container Services, and native apps. It references EGRESS rules and optionally secrets. (Snowflake Docs)

Quick comparison

Aspect	Network Rule	Network Policy	External Access Integration
Purpose	Central list of IPs/hosts/ports	Restrict inbound access	Restrict outbound access
Lives where	Database schema object	Account object	Integration object
Mode	INGRESS / INTERNAL STAGE / EGRESS	Uses INGRESS/INTERNAL STAGE rules	Uses EGRESS rules
Typical use	Reuseable allowlists	Lock client IPs & private endpoints	Permit limited API domains/ports
Applied to	Referenced by others	Account / user / integration	UDFs, procedures, Notebooks, apps

(See Snowflake docs for each: network rules, policies, and external access.) (Snowflake Docs)

Real examples (copy/paste friendly)

Assumptions: you have a SECURITYADMIN/ACCOUNTADMIN style role for policy binding; OWNERSHIP on the schema that will store rules.

1) Define reusable network rules

Inbound (INGRESS) by IP/CIDR and Private Endpoint:

-- Central place to store security objects
CREATE SCHEMA IF NOT EXISTS SECURITY.NETWORK;

-- Allow office and VPN ranges
CREATE OR REPLACE NETWORK RULE SECURITY.NETWORK.ALLOW_CORP_IPS
  MODE = INGRESS
  TYPE = IPV4
  VALUE_LIST = ('203.0.113.0/24','198.51.100.10');

-- Allow a specific cloud private endpoint
CREATE OR REPLACE NETWORK RULE SECURITY.NETWORK.ALLOW_AZURE_PE
  MODE = INGRESS
  TYPE = AWSVPCEID  -- or cloud-specific ID type as supported
  VALUE_LIST = ('vpce-abc123');

MODE=INGRESS rules are later referenced by a network policy. Private endpoint identifiers are supported rule values. (Snowflake Docs)

Outbound (EGRESS) for API domains/ports:

CREATE OR REPLACE NETWORK RULE SECURITY.NETWORK.ALLOW_API_EGRESS
  MODE = EGRESS
  TYPE = HOST_PORT
  VALUE_LIST = ('api.mycompany.com:443','status.myvendor.com:443');

Use HOST_PORT for domain:port pairs in egress. (Snowflake Docs)

2) Bind inbound control with a network policy

CREATE OR REPLACE NETWORK POLICY SECURITY.STRICT_INGRESS
  ALLOWED_NETWORK_RULES = (SECURITY.NETWORK.ALLOW_CORP_IPS, SECURITY.NETWORK.ALLOW_AZURE_PE);
-- Optional: you can also combine with explicit IPs as needed

Attach at account or user scope:

-- Account-level (be careful—affects everyone)
ALTER ACCOUNT SET NETWORK_POLICY = SECURITY.STRICT_INGRESS;

-- Or safer: apply to a specific user first
ALTER USER ALEX SET NETWORK_POLICY = SECURITY.STRICT_INGRESS;

Network policies control inbound access to Snowflake (and, with parameters, internal stages). They consume INGRESS rules. (Snowflake Docs)

3) Bind outbound control with an External Access Integration (EAI)

CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION SECURITY.API_EAI
  ALLOWED_NETWORK_RULES = (SECURITY.NETWORK.ALLOW_API_EGRESS)
  ALLOWED_AUTHENTICATION_SECRETS = (SECURITY.SECRET_VENDOR_TOKEN);

-- Use in a Python procedure
CREATE OR REPLACE PROCEDURE UTIL.CALL_VENDOR_API()
RETURNS STRING
LANGUAGE PYTHON
RUNTIME_VERSION = '3.11'
PACKAGES = ('requests')
EXTERNAL_ACCESS_INTEGRATIONS = (SECURITY.API_EAI)
SECRETS = ('VENDOR_TOKEN' = SECURITY.SECRET_VENDOR_TOKEN)
AS
$$
import os, requests
token = os.environ['VENDOR_TOKEN']
r = requests.get('https://api.mycompany.com/health', headers={'Authorization': f'Bearer {token}'})
return f"Status {r.status_code}"
$$;

EAI references EGRESS rules; procedures/UDFs/Notebooks opt in via EXTERNAL_ACCESS_INTEGRATIONS and secrets. (Snowflake Docs)

Operational tips, best practices, and common pitfalls

Best practices

Centralize security objects. Keep rules in a dedicated schema like SECURITY.NETWORK for auditability and reuse. (DataTools Pro)
Separate inbound vs outbound. Use MODE=INGRESS for policies and MODE=EGRESS for EAIs—don’t mix. (Snowflake Docs)
Prefer named rules over raw IPs. It shortens change windows and reduces copy errors. Consumers (policies/EAIs) stay stable while you update the rule. (Snowflake Docs)
Use Snowflake-managed rules when available. Example: allow PyPI install in Snowpark/Notebooks with snowflake.external_access.pypi_rule. (Snowflake Docs)
Version and describe. Prefix rules and add comments: ALLOW_, BLOCK_, region tags, ticket IDs.

Common pitfalls

Forgetting the mode. An EGRESS rule won’t work with a network policy; an INGRESS rule won’t enable API calls. (Snowflake Docs)
Assuming rules imply allow/deny. They’re neutral containers; the policy/integration decides the enforcement logic. (Snowflake Docs)
Not enabling stage protection (AWS). To extend INGRESS control to certain internal stages, check the ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES behavior. (Snowflake Docs)
Hardcoding secrets in code. Use Snowflake secrets and tie them to EAIs. (Snowflake Docs)
Applying policy at account too early. Test on a pilot user first; you can lock out teams if IPs are incomplete. (Snowflake Docs)

Verification & visibility

Discover rules
SHOW NETWORK RULES; (counts only) and the NETWORK_RULES view to inspect contents; Snowflake-managed rules live in SNOWFLAKE.NETWORK_SECURITY. (Snowflake Docs)
Trace bindings
- DESCRIBE NETWORK POLICY … to see which rules are referenced.
- DESCRIBE INTEGRATION … for EAIs and their allowed rules. (Snowflake Docs)

Real-world pattern: Controlled egress for vendor APIs

Goal: Let a finance UDF call api.vendor.com over 443 and nothing else.

Create SECURITY.NETWORK.ALLOW_VENDOR_API (EGRESS HOST_PORT) with api.vendor.com:443.
Create SECURITY.API_EAI referencing that rule and a token secret.
In the UDF/proc, set EXTERNAL_ACCESS_INTEGRATIONS=(SECURITY.API_EAI) and use the secret.
Add a CI gate to require a code review if the rule’s VALUE_LIST changes.

This gives you a single, auditable allowlist for that integration and ensures developers can’t “just try” other domains. (Snowflake Docs)

Conclusion & takeaways

Network rules are your single source of truth for network identifiers.
Network policies (with INGRESS rules) secure inbound access.
External access integrations (with EGRESS rules) secure outbound calls and work with secrets.
Centralize, name consistently, and test at user scope before enforcing globally. (Snowflake Docs)

Internal link ideas (for your site)

“Snowflake Network Policies: Account vs User Scope Explained”
“Securing External Functions vs External Access: What’s the Difference?”
“Secrets in Snowflake: Patterns for API Tokens”
“Building Least-Privilege Snowpark Container Services”
“Automated Governance: Detecting Rule Drift with DESCRIBE/SHOW”

Image prompt (for AI tools)

“A clean, modern diagram showing Snowflake with two flows: INGRESS via Network Policy referencing INGRESS Network Rules (IPs, private endpoints), and EGRESS via External Access Integration referencing EGRESS Network Rules (host:port). Minimalist, high-contrast, 3D isometric style, labeled arrows, security icons.”

Data/ML Engineer Blog