What you will be able to do
- Create network rules with the right privilege, TYPE and MODE, and know which of their properties can be changed afterwards
- Predict how a network policy evaluates its allowed and blocked lists, including when private-connectivity rules are present
- Work out which policy applies when the account, a user and a security integration each have a network policy
Key concept
Network rule inside a network policy — A network rule is a schema-level list of network identifiers of a single type. It does not allow or block anything by itself. A network policy places rules in its allowed or blocked list, and the policy has to be activated on an account, a user or a security integration before it does anything.
1.Network rules: schema objects that group identifiers
By default, Snowflake accepts connections to the service and to the internal stage from any device. To restrict inbound traffic you use two kinds of object. The first is the network rule, a schema-level object that holds a list of network identifiers. All the identifiers in one rule are the same type. A rule doesn't say whether those identifiers are allowed or blocked. The feature that references the rule decides that. Network policies use rules for traffic coming into Snowflake. External network access uses them to limit where a UDF or procedure can send requests.
To create a rule you need the CREATE NETWORK RULE privilege on its schema. By default only ACCOUNTADMIN, SECURITYADMIN and the schema owner have this privilege. The documentation shows the least-privilege pattern: grant a custom role USAGE on the database and schema plus CREATE NETWORK RULE, then create the rule as that role.
Checkpoint 1 of 6· Fill the gap
This sample creates a rule that a network policy will use to restrict incoming requests from an IP range. Which MODE value completes it?
GRANT USAGE ON DATABASE securitydb TO ROLE network_admin; GRANT USAGE ON SCHEMA securitydb.myrules TO ROLE network_admin; GRANT CREATE NETWORK RULE ON SCHEMA securitydb.myrules TO ROLE network_admin; USE ROLE network_admin; CREATE NETWORK RULE cloud_network TYPE = IPV4 MODE = ? VALUE_LIST = ('47.88.25.32/27');Network policies restrict incoming traffic, so the rule uses INGRESS. EGRESS is for outbound external network access, and INTERNAL_STAGE only accepts AWSVPCEID identifiers.
Source: docs.snowflake.comSnowflake recommends many small, targeted rules over one large IP list. For example, you might have one rule for North American client ranges and another for Europe and the Middle East, a rule for highly privileged users and service users, or a rule for a data app. Put each rule's purpose in its COMMENT property, because SHOW NETWORK RULES lists comments too. To audit rules and where they are used, call the NETWORK_RULE_REFERENCES Information Schema table function, or query the NETWORK_RULES or NETWORK_RULE_REFERENCES Account Usage views.
Rules are only partly editable. With ALTER NETWORK RULE (or the Edit option in Snowsight) you can change a rule's identifier list and comment. You cannot change its type, mode, name or schema. To change any of those, you need a new rule.
Checkpoint 2 of 6· Check yourself
A rule created as TYPE = IPV4, MODE = INGRESS now needs to hold AWS VPCE IDs. What should the administrator do?
Only the identifiers and the comment can be changed. Type, mode, name and schema are fixed, and every identifier in a rule must match its TYPE.
“You can modify the identifiers and comment of an existing network rule, but you cannot modify its type, mode, name, or schema.”Source: docs.snowflake.com
Sources1
2.TYPE and MODE decide what a rule can protect
A rule's TYPE sets which identifiers it can hold. For incoming requests, the supported types are:
- IPv4 addresses, in CIDR notation.
- IPv6 addresses. These work on AWS only, and you must first set the ENABLE_DUAL_STACK_LOAD_BALANCER account parameter to TRUE.
- VPCE IDs of AWS VPC endpoints. Plain VPC IDs are not supported.
- LinkIDs of Azure private endpoints, which you can get with SYSTEM$GET_PRIVATELINK_AUTHORIZED_ENDPOINTS.
- pscConnectionIDs of Google Cloud Private Service Connect endpoints, which you can get with gcloud compute forwarding-rules describe.
For dual-stack clients, create separate IPv4 and IPv6 rules.
MODE sets the direction and the target. Each combination of MODE and TYPE protects something different, which the table below summarises.
| MODE | TYPE | What it restricts |
|---|---|---|
| INGRESS | IPV4 | Snowflake service; also an AWS internal stage once ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES is enabled |
| INGRESS | IPV6 (AWS only) | Snowflake service only; never internal stages |
| INGRESS | AWSVPCEID, AZURELINKID, GCPPSCID | Snowflake service only |
| INTERNAL_STAGE | AWSVPCEID | AWS internal stage, without restricting the service |
| SNOWFLAKE_MANAGED_STORAGE_VOLUME | AWSVPCEID | AWS Snowflake-managed storage volume, without restricting the service |
| EGRESS | Domains, including a port range | Outbound requests from a UDF or procedure (external network access) |
Rules of type AWSVPCEID, AZURELINKID and GCPPSCID in INGRESS mode also accept a tuple syntax, {private_link_id:ip_or_cidr[,ip_or_cidr, ...]}. A tuple pairs an endpoint ID with specific IPv4 addresses or ranges. Use tuples when several VPCs, VNets or accounts share one PrivateLink endpoint or transit gateway and you need to limit which workloads behind it can connect. In a simple one-endpoint-to-one-VPC setup, ordinary rules are usually enough.
Checkpoint 3 of 6· Check yourself
Two business units reach Snowflake through the same VPC endpoint, and their private IP ranges overlap. Only one unit's subnet should be allowed. Which rule fits?
Because the IP ranges overlap, the IP alone can't tell the units apart, and the VPCE ID alone admits both. A tuple matches on the endpoint and the IP together. VPC IDs are not supported at all.
“Snowflake evaluates the combination of the PrivateLink ID and private IP, not the IP alone, to allow or block traffic.”Source: docs.snowflake.com
Sources1
3.How a network policy evaluates its allowed and blocked lists
The second object is the network policy. It has an allowed list and a blocked list, and it fills both with rules rather than raw addresses. Policies created before network rules existed, which use the ALLOWED_IP_LIST and BLOCKED_IP_LIST parameters, still work. However, new policies should use rules, and you should avoid mixing both methods in one policy. Those older policies can't be edited in Snowsight; use ALTER NETWORK POLICY instead.
Checkpoint 4 of 6· Put it in order
Put the network policy workflow in order
- 1.Create a network policy that adds those rules to its allowed or blocked list
- 2.Activate the policy for an account, user, or security integration
- 3.Create network rules grouped by purpose and identifier type
A policy is built from rules, and it restricts nothing until it is activated.
“A network policy doesn’t restrict network traffic until it is activated.”Source: docs.snowflake.com
Four evaluation rules explain most policy behaviour:
1. The allowed list implies a block. If an IPv4 rule is in the allowed list, every other IPv4 address is blocked. You don't need to add the rest to the blocked list. 2. Blocked wins on overlap. If the same value appears in both lists, Snowflake applies the blocked list first. 3. Private-connectivity rules take precedence. If a request arrives over private connectivity and the allowed list contains an AWSVPCEID or AZURELINKID rule, all IPv4 and IPv6 rules are ignored for that request. 4. Endpoint rules ignore the public internet. A rule built from VPCE IDs or LinkIDs has no effect on requests from public addresses. To allow an endpoint and also shut out public traffic, you need two rules: one in the allowed list and one in the blocked list.
A policy can hold both IPv4 and IPv6 rules, and each request is checked against both types independently. A request that arrives over IPv6 when the policy has no IPv6 rules is checked against the IPv4 rules only.
CREATE NETWORK RULE block_public_access
MODE = INGRESS
TYPE = IPV4
VALUE_LIST = ('0.0.0.0/0');
CREATE NETWORK RULE allow_vpceid_access
MODE = INGRESS
TYPE = AWSVPCEID
VALUE_LIST = ('vpce-0fa383eb170331202');
CREATE NETWORK POLICY allow_vpceid_block_public_policy
ALLOWED_NETWORK_RULE_LIST = ('allow_vpceid_access')
BLOCKED_NETWORK_RULE_LIST=('block_public_access');Checkpoint 5 of 6· Check yourself
An administrator activates a policy whose only rule is an AWSVPCEID rule in the allowed list. What happens to a request from a public IPv4 address?
The implicit block from an allowed list applies within one identifier type. A private-endpoint rule doesn't apply to public requests at all, which is why the documented pattern pairs it with a blocked 0.0.0.0/0 IPV4 rule.
“has no effect on requests coming from the public network.”Source: docs.snowflake.com
Sources2
4.Account, user and security integration: which policy wins
A policy can be activated on an account, a user or a security integration. If more than one applies to a request, the most specific one wins, and the lists are never combined.
- Account is the most general level. A user or security integration policy overrides it. - User overrides the account but is overridden by a security integration. - Security integration is the most specific level and overrides both.
There is one exception for Snowflake OAuth. For client-to-Snowflake traffic such as token requests, the user-level policy is not considered; only the integration-level and account-level policies apply. The built-in SNOWFLAKE$LOCAL_APPLICATION integration is the exception to the exception, because it also enforces the user-level policy on token requests.
A policy can be bypassed temporarily through the user property MINS_TO_BYPASS_NETWORK_POLICY, which DESCRIBE USER displays. Only Snowflake Support can set it. Snowflake recommends scoping policies narrowly, to groups of users or to a security integration rather than the whole account where possible. That is why a rule for privileged users and service users fits well into a user-level policy.
Checkpoint 6 of 6· Check yourself
A custom Snowflake OAuth integration has a network policy, the account has another policy, and the requesting user has a third. Which policies govern the client's token request?
For Snowflake OAuth client-to-Snowflake traffic such as token requests, the user-level policy is skipped. Only the built-in SNOWFLAKE$LOCAL_APPLICATION integration also enforces it.
“For Snowflake OAuth, the user-level network policy is not considered for client-to-Snowflake traffic such as token requests.”Source: docs.snowflake.com
Sources2
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.To allow one IP range, you must also put every other range in the blocked list.Why is that wrong?
Putting a rule in the allowed list automatically blocks all other identifiers of the same type. The blocked list is only needed for exceptions, such as one address inside an allowed range.
Covered in How a network policy evaluates its allowed and blocked lists
2.Allowing only a VPCE ID automatically locks out the public internet.Why is that wrong?
Private-endpoint rules don't apply to public requests. To block public traffic you need a separate IPv4 rule, such as 0.0.0.0/0, in the blocked list.
Covered in How a network policy evaluates its allowed and blocked lists
3.When the account and a user both have network policies, Snowflake merges their allowed lists.Why is that wrong?
The most specific policy replaces the more general one: user overrides account, and security integration overrides both.
Covered in Account, user and security integration: which policy wins
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Network rules are schema-level objects that group network identifiers into logical units.”
↩︎ Network rules: schema objects that group identifiers“By default, only the ACCOUNTADMIN and SECURITYADMIN roles, along with the schema owner, have this privilege.”
↩︎ Network rules: schema objects that group identifiers“IPv6 network rules only support the INGRESS mode and protect the Snowflake service. They don’t protect internal stages.”
↩︎ TYPE and MODE decide what a rule can protect“VPC IDs are not supported.”
↩︎ TYPE and MODE decide what a rule can protect“A network rule does not define whether its identifiers should be allowed or blocked.”
↩︎ Key concept“You can modify the identifiers and comment of an existing network rule, but you cannot modify its type, mode, name, or schema.”
↩︎ Checkpoint“If TYPE=IPV4, by default the network rule controls access to the Snowflake service only.”
↩︎ Prediction“Snowflake evaluates the combination of the PrivateLink ID and private IP, not the IP alone, to allow or block traffic.”
↩︎ Checkpoint - 2.
“all new network policies should use network rules, not the ALLOWED_IP_LIST and BLOCKED_IP_LIST parameters”
↩︎ How a network policy evaluates its allowed and blocked lists“If an incoming request uses private connectivity and there is a network rule of type AWSVPCEID or AZURELINKID in the ALLOWED_NETWORK_RULE_LIST property”
↩︎ How a network policy evaluates its allowed and blocked lists“Network policies applied to a security integration are the most specific network policies. They override both accounts and users.”
↩︎ Account, user and security integration: which policy wins“Only Snowflake can set the value for this object property.”
↩︎ Account, user and security integration: which policy wins“if you add an IPv4 network rule with a single IP address to the allowed list, all other IPv4 addresses are blocked.”
↩︎ Exam trap 1“has no effect on requests coming from the public network.”
↩︎ Exam trap 2“the most specific network policy overrides more general network policies.”
↩︎ Exam trap 3“A network policy doesn’t restrict network traffic until it is activated.”
↩︎ Checkpoint“has no effect on requests coming from the public network.”
↩︎ Checkpoint“Network policies applied to a user override network policies applied to the account”
↩︎ Prediction“For Snowflake OAuth, the user-level network policy is not considered for client-to-Snowflake traffic such as token requests.”
↩︎ Checkpoint