Network Policies¶
Network policies provide options for managing network configurations to the Snowflake service.
Network policies allow restricting access to your account based on user IP address. Effectively, a network policy enables you to create an IP allowed list, as well as an IP blocked list, if desired.
Note
Network rules, which are currently in Preview, can be combined with network policies to restrict network access. Network rules have the following benefits:
Groups network identifiers into logical units before using a network policy to block or allow those identifiers.
Can restrict requests originating from private connectivity endpoints (AWS VPC endpoints and Azure private endpoints).
Restricts access to both the Snowflake service and internal stages.
Snowflake strongly recommends that all new network policies should be implemented using network rules to specify the allowed or blocked identifiers.
For more details, see Working with Network Rules.
Overview¶
By default, Snowflake allows users to connect to the service from any computer or device IP address. A security administrator (or higher) can create a network policy to allow or deny access to a single IP address or a list of addresses. Network policies currently support only Internet Protocol version 4 (i.e. IPv4) addresses.
An administrator with sufficient permissions can create any number of network policies. A network policy is not enabled until it is activated at the account or individual user level. To activate a network policy, modify the account or user properties and apply the network policy to the object. Only a single network policy can be applied to the account or a specific user at a time.
A network policy can also be applied to some types of security integrations.
Network Policy Precedence¶
A network policy can be applied to an account, a security integration, or a user. If there are network policies applied to more than one of these, the most specific network policy overrides more general network policies. The following summarizes the order of precedence:
- Account
Network policies applied to an account are the most general network policies. They are overridden by network policies applied to a security integration or user.
- Security Integration
Network policies applied to a security integration override network policies applied to the account, but are overridden by a network policy applied to a user.
- User
Network policies applied to a user are the most specific network policies. They override both accounts and security integrations.
CIDR Notation¶
Snowflake supports specifying ranges of IP addresses using Classless Inter-Domain Routing (i.e. CIDR) notation. In CIDR notation, the optional subnet is expressed as a decimal number that represents the prefix length:
ip_address[/prefix_length]
For example, 192.168.1.0/24
represents all IP addresses in the range of 192.168.1.0
to 192.168.1.255
.
Examples of Allowed / Blocked Address Lists¶
Snowflake does not allow setting a network policy that blocks your current IP address. An error message results while trying to create a network policy that blocks the current IP address.
The following are representative examples to define allowed and blocked IP address ranges using a Snowflake network policy.
Allow all IP addresses in the range of 192.168.1.0
to 192.168.1.255
, except 192.168.1.99
, which is explicitly blocked. In addition,
all other IP addresses are blocked:
- Allowed IP Addresses: 192.168.1.0/24 - Blocked IP Addresses: 192.168.1.99
Allow only the 192.168.1.0
and 192.168.1.100
IP addresses to access your account:
- Allowed IP Addresses: 192.168.1.0,192.168.1.100 - Blocked IP Addresses: N/A
Bypassing a Network Policy¶
It is possible to temporarily bypass a network policy for a set number of minutes by configuring the user object property
MINS_TO_BYPASS_NETWORK_POLICY
, which can be viewed by executing DESCRIBE USER. Only Snowflake can set the
value for this object property. Please contact Snowflake Support to set a value for this property.
Creating Network Policies¶
Note
Only security administrators (i.e. users with the SECURITYADMIN role) or higher or a role with the global CREATE NETWORK POLICY privilege can create network policies. Ownership of a network policy can be transferred to another role.
You can create a network policy using Snowsight, the Classic Console, or SQL:
- Snowsight
Click Admin » Security » Network Policies.
Click the + Network Policy button in the top-right corner of the page. The New network policy dialog opens.
Specify the following properties:
Property
Description
Policy Name
Identifier for the network policy; must be unique for your account.
The identifier must start with an alphabetic character and cannot contain spaces or special characters unless the entire identifier string is enclosed in double quotes (e.g.
"My object"
).Identifiers enclosed in double quotes are also case-sensitive.
For more details, see Identifier requirements.
Allowed IP Addresses
Comma-separated list of one or more IPv4 addresses that are allowed access to your Snowflake account. This is referred to as the allowed list. Snowflake automatically blocks all IP addresses not included in the allowed list.
Each IP address can cover a range of addresses using Classless Inter-Domain Routing (CIDR) notation.
For information, see CIDR Notation (in this topic).
For examples, see Examples of Allowed / Blocked Address Lists (in this topic).
Blocked IP Addresses
Comma-separated list of one or more IPv4 addresses that are denied access to your Snowflake account. This is referred to as the blocked list.
Set this parameter only when you are allowing access to a range of IP addresses in the Allowed IP Addresses list and want to deny access to one or more IP addresses within the range.
Each IP address can cover a range of addresses using Classless Inter-Domain Routing (CIDR) notation.
For information, see CIDR Notation (in this topic).
For examples, see Examples of Allowed / Blocked Address Lists (in this topic).
Comment
Specifies a comment for the network policy.
Click the Create network policy button.
- Classic Console
Click the Create button. The Create Network Policy dialog appears.
In the Name field, enter a name for the network policy.
In the Allowed IP Addresses field, enter one or more IPv4 addresses that are allowed access to this Snowflake account, separated by commas.
Note
To block all IP addresses except for a set of specific addresses, you only need to define an allowed IP address list. Snowflake automatically blocks all IP addresses not included in the allowed list.
In the Blocked IP Addresses field, optionally enter one or more IPv4 addresses that are denied access to this Snowflake account, separated by commas. Note that this field is not required and is used primarily to deny specific addresses in a range of addresses in the allowed list.
Caution
When a network policy includes values in both the allowed and blocked IP address lists, Snowflake applies the blocked IP address list first.
Do not add
0.0.0.0/0
to the blocked IP address list.0.0.0.0/0
is interpreted to be “all IPv4 addresses on the local machine”. Because Snowflake resolves this list first, this would block your own access. Also, note that it is not necessary to include this IP address in the allowed IP address list.
Enter other information for the network policy, as needed, and click Finish.
- SQL
Execute a CREATE NETWORK POLICY statement.
Viewing Network Policies¶
View information about the network policies through Snowsight, the Classic Console, or using SQL:
Note
Only the role with the OWNERSHIP privilege on the network policy, or a higher role, can view details on the network policy.
- Snowsight
Select Admin » Security » Network Policies » <policy_name>.
- Classic Console
- SQL
Execute one of the following statements:
Activating a Network Policy for Your Account¶
To enforce a network policy for all users in your Snowflake account, activate the network policy for your account.
Note
If a network policy is activated for an individual user, the user-level network policy takes precedence. For information about activating network policies at the user level, see Activating Network Policies for Individual Users (in this topic).
Note
This action is limited to either of the following roles:
Security administrators (i.e. users with the SECURITYADMIN role), or a higher role.
A role that has been granted the global ATTACH POLICY privilege.
Once the policy is associated with your account, Snowflake restricts access to your account based on the allowed IP address list and blocked IP address list. Any user who attempts to log in from an IP address restricted by the rules is denied access. In addition, when a network policy is associated with your account, any restricted users who are already logged into Snowflake are prevented from executing further queries.
A security administrator (or higher) can create multiple network policies; however, only one network policy can be associated with an account at any one time. Associating a network policy with your account automatically removes the currently-associated network policy (if any).
Note that your current IP address must be included in the allowed IP addresses list in the policy. Otherwise, when you activate the policy, Snowflake returns an error. In addition, your current IP address cannot be included in the blocked IP addresses list.
You can associate a network policy with your account using Snowsight, the Classic Console, or SQL:
- Snowsight
Click Admin » Security » Network Policies.
Click the Activate Policy button to the right of the policy that you are activating.
- Classic Console
- SQL
Execute an ALTER ACCOUNT statement that sets the network policy using the NETWORK_POLICY account parameter.
Activating Network Policies for Individual Users¶
To enforce a network policy for an specific user in your Snowflake account, activate the network policy for the user. Only a single network policy can be activated for each user at a time; however, different network policies can be activated for different users for granular control. Associating a network policy with a user automatically removes the currently-associated network policy (if any).
Note
Only the role with the OWNERSHIP privilege on both the user and the network policy, or a higher role, can activate a network policy for an individual user.
Once the policy is associated with the user, Snowflake restricts access to the user based on the allowed IP address list and blocked IP address list. If the user with an activated user-level network policy attempts to log in from an IP address restricted by the rules, the user is denied access to Snowflake.
In addition, when a user-level network policy is associated with the user and the user is already logged into Snowflake, if the user’s IP address does not match the user-level network policy rules, Snowflake prevents the user from executing further queries.
To activate a network policy for an individual user, set the NETWORK_POLICY parameter for the user using ALTER USER.
Modifying Network Policies¶
Network policies can be modified through Snowsight, the Classic Console, or SQL, specifically to add or remove IP addresses from the list of allowed and blocked addresses.
For descriptions of the network policy properties, see Creating Network Policies (in this topic).
- Snowsight
Click Admin » Security » Network Policies.
Click the actions (…) button in the row for a network policy » Edit Policy. The Edit Policy dialog opens.
Edit any of the properties.
Click the Save changes button.
- Classic Console
Click on a policy to select it and populate the side panel on the right.
Click the Edit button in the right panel.
Modify the fields as necessary:
To remove an IP address from the Allowed IP Addresses or Blocked IP Addresses list, click the x next to the entry.
To add an IP address to either list, enter one or more comma-separated IPv4 addresses in the appropriate field, and click the Add button.
Click Save.
- SQL
Execute an ALTER NETWORK POLICY statement.
Identifying a Network Policy Activated at the Account or User Level¶
To determine whether a network policy is set on your account or for a specific user, execute the SHOW PARAMETERS command.
- Account
SHOW PARAMETERS LIKE 'network_policy' IN ACCOUNT;
- User
SHOW PARAMETERS LIKE 'network_policy' IN USER <username>;
For example:
SHOW PARAMETERS LIKE 'network_policy' IN USER jsmith;
Using Replication with Network Policies¶
Snowflake supports replication and failover/failback for network policies and their assignments from a source account to a target account.
For details, refer to Replication of Security Integrations & Network Policies Across Multiple Accounts.
Working with Network Rules¶
While restrictions on incoming requests to Snowflake are ultimately applied to an account or user with a network policy, the administrator can organize these restrictions using network rules, which are schema-level objects.
Each network rule groups together the identifiers for a particular type of request origin. For example, one network rule might include all of the IPv4 addresses that should be allowed to access Snowflake while another groups together all of the private endpoints that should be blocked.
A network rule, however, does not specify whether it is allowing or blocking the origin of a request. It simply organizes related origins into a logical unit. Administrators specify whether that unit should be allowed or blocked when they create or modify a network policy.
The general workflow is:
Create a network rule for a particular type of network identifier and purpose.
Add that network rule to the allowed rules list or blocked rules list of a network policy.
Apply the network policy to an account, user, or security integration.
Changes to Network Policy Functionality¶
The introduction of network rules changes the way administrators use network policies to control network traffic, including:
When a network policy is using network rules, the policy should not use the ALLOWED_IP_LIST and BLOCKED_IP_LIST parameters to specify individual IP addresses. Do not use both ways to restrict access.
Administrators cannot use Snowsight or Classic Console to create network rules or add network rules to a network policy.
Network rules cannot be replicated. This does not affect the current ability to replicate network policies without network rules.
Limitations¶
In this preview, network rule restrictions don’t apply to requests accessing an internal stage using a presigned URL that has been generated by the GET_PRESIGNED_URL function.
Best Practices¶
Limit the scope. Network rules are designed to group together small units of related network identifiers. Previously, network policies often contained a large, monolithic list of IP addresses that should be allowed or blocked. The introduction of network rules changes this strategy. For example, you could break up network identifiers by:
Creating a network rule to contain client IP addresses for the North American region, and a different rule for the Europe and Middle Eastern region.
Creating a network rule whose purpose is to allow access for a special population, such as highly privileged users and service account users. This network rule can be added to a network policy that is applied to individual users.
Creating a network rule that is scoped to one or more data apps.
With the introduction of network rules, Snowflake recommends that you also limit the scope of network policies. Whenever possible, narrowly scope a network policy to a group of users or a security integration rather than an entire account.
Add comments. When creating a network rule, use the
COMMENT
property to keep track of what the rule is supposed to do. Comments are important because Snowflake encourages a large number of small targeted rules over fewer monolithic ones.You can use the SHOW NETWORK RULES command to list all of the network rules, including their comments.
Supported Identifiers¶
Each network rule contains a list of one or more network identifiers of the same type (e.g. an IPv4 address rule or a private endpoint rule).
A network rule’s TYPE
property identifies what type of identifiers the network rule contains, and the VALUE_LIST
property
specifies those identifiers.
For a complete list of the types of identifiers that can be restricted using network rules, see Supported Network Identifiers.
When you add a network rule to the allowed list of a network policy, you do not have to explicitly block other identifiers of the same type; only the allowed identifiers have access. However, identifiers of a different type are not automatically blocked. For example, if you add an IPV4 network rule with a single IP address to the allowed list, all other IPv4 addresses are blocked. However, VPC endpoints still have access unless additional network rules are used.
As an example, a network rule that uses private endpoint identifiers such as Azure LinkIDs or AWS VPCE IDs to restrict access have no effect on requests coming from the public network. If you want to restrict access based on private endpoint identifiers, and then completely block requests from public IPv4 addresses, you must create two separate network rules.
The following network rules could be combined in a network policy to allow a VPCE ID while blocking public network traffic.
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');
Protecting the Snowflake Service¶
This section discusses how to use network rules to restrict access to the Snowflake service only. If you want to restrict access to both the service and the internal stage of an account on AWS, see Protecting Internal Stages on AWS.
To restrict access to the Snowflake service, set the MODE
property of the network rule to INGRESS
.
You can then use the TYPE
property to specify the identifiers that should be allowed or
blocked.
Protecting Internal Stages on AWS¶
This section discusses how to use network rules to restrict access to internal stages on AWS, including how to simultaneously restrict access to the Snowflake service and internal stage. It includes:
Currently, you cannot use a network policy that is assigned to a security integration to restrict access to an internal stage.
Note
You cannot use a network rule to restrict access to an internal stage on Microsoft Azure. However, you can block all public access to an internal stage on Azure if you are using Azure Private Link. For details, see Blocking Public Access (Optional).
Guidelines for Internal Stages¶
In addition to the best practices for network rules, you should adhere to the following guidelines when creating network rules to restrict access to internal stages.
Limit the number of identifiers. Due to restrictions enforced by AWS S3 session policies, your strategy for protecting an internal stage must conform to the following limits:
A network rule that contains IPv4 addresses cannot contain more than 15 IP address ranges per rule. If you have more than 15 address ranges, create an additional network rule.
When you are allowing or blocking traffic based on the VPCE IDs of VPC endpoints, there is a cumulative limit of 10 VPCE IDs per network policy. For example, if one network rule contains 5 VPCE IDs and another contains 6 VPCE IDs, you cannot add both rules to the same network policy.
If you encounter
PolicySizeExceeded
exceptions when fetching the scoped credentials from AWS STS, break up the network identifiers into smaller network rules.Use same rule to protect both service and internal stage. When a rule contains IPv4 addresses and the mode of a network rule is
INGRESS
, a single rule can protect both the Snowflake service and the internal stage of the account. Snowflake recommends using a single rule even when the IP addresses accessing the service are different from the IP addresses accessing the internal stage. This approach improves organization, manageability, and auditing.Test Network Policies. Snowflake recommends testing network rules using user-level network policies. If you encounter
PolicySizeExceeded
exceptions when fetching the scoped credentials from AWS STS, break up the network identifiers into smaller network rules.
Enabling Internal Stage Restrictions¶
To use network rules to restrict access to the internal stage of an account, the account administrator must enable the ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES parameter . Network rules do not protect an internal stage until this parameter is enabled, regardless of the rule’s mode.
To allow network rules to restrict access to internal stages, execute:
USE ROLE ACCOUNTADMIN;
ALTER ACCOUNT SET ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES = true;
Strategy for Protecting the Internal Stage Only¶
To restrict access to an AWS internal stage without affecting how network traffic accesses the Snowflake service, create a network rule with the following settings:
Set the
MODE
parameter toINTERNAL_STAGE
.Set the
TYPE
parameter toAWSVPCEID
.
Note
You cannot restrict access to the internal stage based on the IP address of the request without also restricting access to the Snowflake service.
Strategies for Protecting Both Service and Internal Stage¶
When restricting access to both the Snowflake service and internal stage, the implementation strategy varies based on whether network traffic is traversing the public internet or AWS Private Link.
In the following comparison, “Public” indicates that traffic to the service or internal stage is traversing the public internet while “Private” indicates traffic is using AWS Private Link. Find the combination that matches your environment, and then choose the implementation strategy accordingly.
Service Connection |
Internal Stage Connection |
Implementation Strategy |
---|---|---|
Public |
Public |
Create a single network rule with |
Private |
Private |
Strategy depends on whether you want to restrict access using private IP addresses or the VPCE ID of the VPC endpoints:
|
Public 1 |
Private |
Strategy depends on whether you want to restrict access to the internal stage using private IP addresses or VPCE ID of the VPC endpoints:
|
Private |
Public 1 |
You must use private IPs for the service (cannot use VPCE IDs). Create a single network rule with |
Creating a Network Rule¶
An administrator can execute the CREATE NETWORK RULE command to create a new network rule, specifying a list of network identifiers along with the type of those identifiers.
Creating a network rule does not define whether it is allowing or blocking the network identifiers. Administrators specify those permissions when adding the network rule to a network policy.
For example, to use a custom role to create a network rule that can be used to allow or block traffic from a range of IP addresses:
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 VALUE_LIST = ('47.88.25.32/27');
Once created, ownership of a network rule can be transferred to another role.
Adding Network Rules to a Network Policy¶
Network rules organize network identifiers and define what gets restricted, but they do not enforce restrictions. Rather, the network rules are added to network policies, which are then applied to an account or user to control access.
An administrator specifies whether the network identifiers of a network rule should be allowed or blocked by adding the rule to the appropriate parameter of a network policy. If you created a case-sensitive name for the network rule, you must use double quotes when assigning it to a network policy.
The ALLOWED_NETWORK_RULE_LIST
parameter of a network policy defines a list of network rules that contain network identifiers that are
allowed. Once you add at least one network rule to this parameter, you do not have to explicitly block other identifiers of the same type;
only the allowed identifiers have access. However, identifiers of a different type are not automatically blocked. For example,
if you add an IPV4 network rule with a single IP address to the allowed list, all other IPv4 addresses are blocked. However, VPC
endpoints still have access unless additional network rules are used.
If you want to explicitly block network identifiers using a network rule, add the rule to the BLOCKED_NETWORK_RULE_LIST
parameter of
the network policy.
Once you have added a network rule to a network policy, you can execute the DESCRIBE NETWORK POLICY command to verify.
Once the network rules have been added to one of the network policy’s parameters, you can attach the policy to an account or user to apply the restrictions.
Examples¶
Create two network rules corp_network
and cloud_network
, then create a network policy that allows the network identifiers in
those rules:
CREATE NETWORK RULE corp_network TYPE = AWSVPCEID VALUE_LIST = ('vpce-123abc3420c1931');
CREATE NETWORK RULE cloud_network TYPE = IPV4 VALUE_LIST = ('47.88.25.32/27');
CREATE NETWORK POLICY account_policy ALLOWED_NETWORK_RULE_LIST = ( 'corp_network', 'cloud_network' );
Modify a network policy, replacing previously blocked network rules with a new network rule named other_network
:
ALTER NETWORK POLICY my_policy SET BLOCKED_NETWORK_RULE_LIST = ( 'other_network' );
Add a single network rule to the allowed list of an existing network policy. Network rules that were previously added to the policy’s allowed list remain in effect.
ALTER NETWORK POLICY my_policy ADD ALLOWED_NETWORK_RULE_LIST = ( 'new_rule' );
Remove a network rule from the network policy’s blocked list:
ALTER NETWORK POLICY my_policy REMOVE BLOCKED_NETWORK_RULE_LIST = ( 'other_network' );