What you will be able to do
- Explain how a network rule differs from the network policy that uses it, and pick the right TYPE and MODE for an identifier
- Predict whether a request is allowed or blocked from a policy's allowed and blocked lists
- Activate a network policy on an account, a user or a security integration, and work out which policy wins when several apply
- Restrict access to an AWS internal stage with network rules, and know where that technique does not apply
Key concept
Network rule vs. network policy — A network rule is a schema-level object that groups identifiers of one type, such as IPv4 ranges or private endpoint IDs. It never says allow or block. That decision belongs to the network policy that puts the rule on its allowed or blocked list, and the policy does nothing until it is activated.
1.Network rules: grouping identifiers by TYPE and MODE
By default, Snowflake accepts connections to the service and the internal stage from any computer or device. Network policies control that inbound access. They do not list addresses themselves. They reference network rules, which are schema-level objects that group related network identifiers into logical units. The same rule objects also appear in external network access, the egress feature that a neighbouring subdomain covers. In this lesson, a rule's job is to describe where an incoming request came from.
Each rule holds identifiers of one kind only, and its TYPE property names that kind. For incoming requests the types are IPV4 (single addresses or CIDR ranges such as 192.168.1.0/24), IPV6 (AWS only), AWSVPCEID (the VPCE ID of an AWS VPC endpoint; VPC IDs are not supported), AZURELINKID (the LinkID of an Azure private endpoint) and GCPPSCID (the pscConnectionID of a Google Cloud Private Service Connect endpoint).
The MODE property sets which traffic the rule governs. With a network policy, INGRESS protects the Snowflake service. INTERNAL_STAGE and SNOWFLAKE_MANAGED_STORAGE_VOLUME protect AWS storage without restricting access to the service. EGRESS is reserved for outbound traffic.
To create a rule you need the CREATE NETWORK RULE privilege on the schema. By default only ACCOUNTADMIN, SECURITYADMIN and the schema owner have it, so a custom network_admin role must be granted it explicitly. After a rule is created, you can edit its identifiers and comment, but not its type, mode, name or schema. Snowflake recommends many small, commented rules over one monolithic list: one rule per region, say, or one rule for privileged and service users that you attach to a user-level policy.
| TYPE | Identifiers it holds | What INGRESS protects | Other modes |
|---|---|---|---|
| IPV4 | IPv4 addresses or CIDR ranges | The service; also an AWS internal stage once ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES is enabled | None |
| IPV6 | IPv6 addresses or CIDR ranges (AWS only) | The service only, never internal stages | INGRESS is the only mode |
| AWSVPCEID | VPCE IDs of AWS VPC endpoints | The service only | INTERNAL_STAGE, SNOWFLAKE_MANAGED_STORAGE_VOLUME |
| AZURELINKID | LinkIDs of Azure private endpoints | The service only | None |
| GCPPSCID | pscConnectionIDs of Google Cloud PSC endpoints | The service only | None |
Checkpoint 1 of 6· Check yourself
An administrator created an IPV4 rule in INGRESS mode and now wants it to be an AWSVPCEID rule. What must they do?
ALTER NETWORK RULE can change only a rule's identifiers and comment. Its type, mode, name and schema are fixed when it is created.
“you cannot modify its type, mode, name, or schema”Source: docs.snowflake.com
Sources1
2.Allowed and blocked lists: how a policy decides
A policy adds rules to ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST. Putting a rule on the allowed list already denies every other identifier of that type, so the blocked list is for exceptions. When the same value appears on both lists, the blocked list is applied first and wins. That precedence is what makes the "range minus one address" pattern work. The policy below admits 192.168.1.0/24 except 192.168.1.99, and addresses outside the range are blocked too.
Older policies set ALLOWED_IP_LIST and BLOCKED_IP_LIST directly. Those policies still work and follow the same blocked-first rule. Snowflake says new policies should use network rules instead, and recommends against mixing both styles in one policy. Pre-rule policies can no longer be modified in Snowsight, so change them with ALTER NETWORK POLICY.
CREATE NETWORK RULE allow_access_rule
MODE = INGRESS
TYPE = IPV4
VALUE_LIST = ('192.168.1.0/24');
CREATE NETWORK RULE block_access_rule
MODE = INGRESS
TYPE = IPV4
VALUE_LIST = ('192.168.1.99');
CREATE NETWORK POLICY public_network_policy
ALLOWED_NETWORK_RULE_LIST = ('allow_access_rule')
BLOCKED_NETWORK_RULE_LIST=('block_access_rule');Checkpoint 2 of 6· Check yourself
A legacy policy lists 10.1.1.5 in both ALLOWED_IP_LIST and BLOCKED_IP_LIST. What happens to a request from 10.1.1.5?
Snowflake applies the blocked values first. The same is true of ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST.
“Snowflake applies the values in the BLOCKED_IP_LIST parameter first”Source: docs.snowflake.com
Sources2
3.Activating policies on accounts, users and security integrations
The workflow has three steps: create rules, create policies that reference them, then activate. A policy restricts nothing until it is activated on an account, a user or a security integration. At account level you set the NETWORK_POLICY parameter. For a user, you need OWNERSHIP on the user and USAGE on the policy, or a higher role. Each user can have only one policy at a time, and associating a new one removes the old one.
ALTER ACCOUNT SET NETWORK_POLICY = my_policy;When policies exist at more than one level, the most specific one wins. A user policy overrides the account policy, and a security integration policy overrides both. That is how you let one integration's traffic in without loosening the account policy: attach a dedicated policy to that integration. Snowflake also recommends scoping policies narrowly, to a group of users or a security integration rather than the whole account, whenever possible.
There are two exceptions to remember. For Snowflake OAuth token requests, user-level policies are ignored and only the integration and account policies apply, except on the built-in SNOWFLAKE$LOCAL_APPLICATION integration. A user's MINS_TO_BYPASS_NETWORK_POLICY property can suspend a policy for a set number of minutes, but only Snowflake Support can set it.
Checkpoint 3 of 6· Put it in order
Put the network policy workflow in order
- 1.Create network policies that add those rules to their allowed and blocked lists
- 2.Activate the policy for an account, user, or security integration
- 3.Create network rules based on their purpose and type of network identifier
Policies reference rules, so the rules come first. A policy does not restrict traffic until it is activated.
“Create network rules based on their purpose and type of network identifier.”Source: docs.snowflake.com
Checkpoint 4 of 6· Check yourself
The account, user svc_etl and a security integration that svc_etl authenticates through each have their own network policy. Which policy governs that traffic?
Precedence runs from account (most general) to user to security integration (most specific). The most specific policy overrides the others.
“Network policies applied to a security integration are the most specific network policies. They override both accounts and users”Source: docs.snowflake.com
Checkpoint 5 of 6· Exam question
An account-level network policy allows only the corporate range 203.0.113.0/24 through an ingress network rule. The service user `svc_etl` has its own user-level network policy that allows 198.51.100.0/24, and no other policies exist. What happens when `svc_etl` connects from 198.51.100.17?
Correct answer: A — The login succeeds, because the user-level policy replaces the account policy for this user and the address falls inside its allowed range.
- A. Correct: Snowflake applies the most specific policy, so the user-level policy is the only one evaluated for this user and the address matches its allowed rule.
- B. Incorrect: evaluation is not layered from the account down; the account policy is skipped when a user-level policy is set.
- C. Incorrect: policies do not combine as an intersection. Only one policy applies at a time, chosen by specificity.
- D. Incorrect: a user-level policy can allow addresses the account policy does not, since it overrides rather than narrows.
Sources2
4.Extending network rules to AWS internal stages
By default, an IPV4 INGRESS rule protects only the service. To protect the internal stage on AWS, the account administrator first enables ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES. After that, IPV4 INGRESS rules cover the stage as well. To restrict the stage by VPC endpoint, create a separate rule with MODE = INTERNAL_STAGE, which must be TYPE = AWSVPCEID. That mode guards the stage without restricting the service. SNOWFLAKE_MANAGED_STORAGE_VOLUME works the same way for Snowflake-managed storage volumes, with its own enforcement parameter.
There are several limits. IPv6 rules never protect stages. A policy activated on a security integration does not restrict the internal stage. On Azure you cannot use a network rule to restrict the internal stage at all. With Azure Private Link you can only block all public access to it.
Checkpoint 6 of 6· Match them up
Match each requirement to the configuration that meets it
Tap a term, then the definition that fits it.
INTERNAL_STAGE mode requires AWSVPCEID and the enforcement parameter. Azure stages cannot be restricted by network rules, and IPv6 rules protect only the service.
“The TYPE property of the network rule must be AWSVPCEID.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.After adding an IPv4 allow rule, you must also add 0.0.0.0/0 to the blocked list to keep everyone else out.Why is that wrong?
Once a type has identifiers on the allowed list, only those identifiers get in. The blocked list is for exceptions inside an allowed range.
2.A user-level network policy overrides the policy on the security integration that user signs in through.Why is that wrong?
The order is account, then user, then security integration. The integration policy is the most specific and overrides both.
Covered in Activating policies on accounts, users and security integrations
3.An AZURELINKID or IPV4 network rule can restrict the internal stage of an Azure account the same way it does on AWS.Why is that wrong?
Network rules cannot restrict internal stages on Azure. The only option there is to block all public access, which requires Azure Private Link.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“By default, only the ACCOUNTADMIN and SECURITYADMIN roles, along with the schema owner, have this privilege.”
↩︎ Network rules: grouping identifiers by TYPE and MODE“VPC IDs are not supported.”
↩︎ Network rules: grouping identifiers by TYPE and MODE“If the account administrator enables the ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES parameter, then MODE=INGRESS and TYPE=IPV4 also protects an AWS internal stage.”
↩︎ Extending network rules to AWS internal stages“For accounts on Microsoft Azure, you cannot use a network rule to restrict access to the internal stage.”
↩︎ Exam trap 3“you cannot modify its type, mode, name, or schema”
↩︎ Checkpoint“The TYPE property of the network rule must be AWSVPCEID.”
↩︎ Checkpoint - 2.
“all new network policies should use network rules, not the ALLOWED_IP_LIST and BLOCKED_IP_LIST parameters, to control access from IP addresses”
↩︎ Allowed and blocked lists: how a policy decides“Only a single network policy can be activated for each user at a time.”
↩︎ Activating policies on accounts, users and security integrations“Whenever possible, narrowly scope a network policy to a group of users or a security integration rather than an entire account.”
↩︎ Activating policies on accounts, users and security integrations“For Snowflake OAuth, the user-level network policy is not considered for client-to-Snowflake traffic such as token requests.”
↩︎ Activating policies on accounts, users and security integrations“Only Snowflake can set the value for this object property.”
↩︎ Activating policies on accounts, users and security integrations“A network policy that is activated for a security integration does not restrict access to an internal stage.”
↩︎ Extending network rules to AWS internal stages“A network rule, however, does not specify whether it is allowing or blocking the origin of a request.”
↩︎ Key concept“you do not have to use the blocked list to explicitly block other identifiers of the same type; only the allowed identifiers have access”
↩︎ Exam trap 1“Network policies applied to a security integration are the most specific network policies. They override both accounts and users”
↩︎ Exam trap 2“you do not have to use the blocked list to explicitly block other identifiers of the same type; only the allowed identifiers have access”
↩︎ Prediction“Snowflake applies the values in the BLOCKED_IP_LIST parameter first”
↩︎ Checkpoint“Create network rules based on their purpose and type of network identifier.”
↩︎ Checkpoint“Network policies applied to a security integration are the most specific network policies. They override both accounts and users”
↩︎ Checkpoint