Snowflake Network Security and Policies

By Mike M, . Permalink Data › Snowflake

Want to lock down your Snowflake account? Maybe you want to open it up! Using Network Policies and Network Rules, you can add fine-grained access control to your Snowflake world.

Snowflake uses a two-tier structure to allow and restrict access - Network Policies, and Network Rules. The rules specify the objects which are to be allowed or restricted - a list of IP addresses, for instance. The rule also specifies whether the rule is configured for inbound (INGRESS) or outbound (EGRESS) access. On their own, the rules are useless - they have to be associated to a Network Policy. The policy can have an unlimited number of rules associated with it, and once the policy is activated, so too are the rules.

You'll be tested on policies and rules as part of the SnowPro Core exam's Outline Security Principals section, which includes Network security and policies. This is part of the Account Access and Security section, which covers a sizeable 20-25% of the marks! For most Data Engineers, security isn't the sexiest of subjects, but it's massively important - and with the number of marks available, it's vital you learn all about it!

What do Network Policies Protect?

Network policies control inbound access to Snowflake and internal stages. By default, anybody can connect from anywhere. This is OK if you have your own little Snowflake account, but it's not so good if you're a bank and your Snowflake account is harvesting customer data. So, security is a must! Especially in this Internet age, when systems are under constant bombardment.

Who can Configure Network Policies?

To set up policies, you must at least hold the SECURITYADMIN role. Only ACCOUNTADMIN and SECURITYADMIN can create network rules by default. You can grant the CREATE NETWORK RULE privilege to other accounts as needed. Network rules are created by using Snowsight or SQL.

How do Network Policies and Network Rules Work in Snowflake?

Network Policies use Network Rules. A rule is a logical unit that groups network identifiers together. Network rules exist at the schema level. They are collections of objects which a Network Policy will use to dictate whether those objects are allowed or blocked. Snowflake used to just use Network Policies, but the rules/policies combination is the way to go these days.

It's a good practice to keep the lists associated with a Network Rule small, e.g. break down IP address lists by region. Don't maintain one huge list of IP addresses.

What can you Allow or Block?

Inbound requests support the creation of policies and rules for IPv4 addresses, VPCE IDs from AWS VPC endpoints, and LinkIDs of Azure private endpoints. Outbound requests support domains, including port ranges. Snowflake's document portal has a detailed article on this.

The process to create and activate a Network Policy is:

1. Create the required network rules, using either Snowsight or SQL.
2. Create the appropriate network policies, adding the required network rules. Again, this can be done using either Snowsight or SQL.
3. Activate the network policy against the desired objects. The policy won't do anything until it is activated.

Three Snowflake entities can be secured:

  • Account
  • User
  • Security Integration

A Security Integration can be created using CREATE SECURITY INTEGRATION. It provides an interface between Snowflake and a third-party service, such as an API.

Network Policies are applied using a particular order of precedence:

  • User - these use the most specific Network Policies. Policies applied here override policies applied to security integrations and accounts
  • Security integration - policies applied here override Network Policies applied to the account
  • Account - uses the most general Network Policies

Locking Yourself Out!

If you're not careful or you're not 100% sure what you are doing when it comes to Snowflake Network Policies, you may lock yourself out of your account! If you do, don't panic! Snowflake support can temporarily bypass a Network Policy, which you may need if you accidentally set up a policy which blocks you! Each user account has a property named MINS_TO_BYPASS_NETWORK_POLICY. This configures the number of minutes the policy is disabled for, just for that user account. You will need to contact Snowflake support directly to enable this.

Creating a Network Rule

To create policies or rules in Snowsight, go to Admin > Security. You'll see tabs for Network Policies and Network Rules.

You can click on the appropriate CREATE button to create a rule or policy. Here's the Network Rule creation screen:

Let's try an example. We want to create and enable a policy which only allows IP addresses in the range 192.168.1.1 to 192.168.1.20 to have access to Snowflake. We'll start off by creating a Network Rule using SQL. Unsurprisingly, this uses the SQL command CREATE NETWORK RULE. Rules can be created for a single IP address, or for a range of IP addresses.

CREATE OR REPLACE NETWORK RULE IpRangeRule
    TYPE = IPV4
    VALUE_LIST = '192.168.1.1/20',
    COMMENT = 'Limits inbound IP range to 192.168.1.1 to 192.168.1.20';

With the rule in place, you can go ahead and associate it with a Network Policy. You'd never guess that this is done using CREATE NETWORK POLICY! This command supports a few list parameters, here's the definition:

CREATE [ OR REPLACE ] NETWORK POLICY <name>
   [ ALLOWED_NETWORK_RULE_LIST = ( '<network_rule>' [ , '<network_rule>' , ... ] ) ]
   [ BLOCKED_NETWORK_RULE_LIST = ( '<network_rule>' [ , '<network_rule>' , ... ] ) ]
   [ ALLOWED_IP_LIST = ( [ '<ip_address>' ] [ , '<ip_address>' , ... ] ) ]
   [ BLOCKED_IP_LIST = ( [ '<ip_address>' ] [ , '<ip_address>' , ... ] ) ]
   [ COMMENT = '<string_literal>' ]

The ALLOWED_IP_LIST and BLOCKED_IP_LIST parameters allow IP addresses to be specified, but as we've already discussed you should follow best practice and create a set of Network Rules to house your IP addresses. If the same IP address is present in both lists, the blocked list takes precedence. This also applies to the lists ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST.

Here's the command to create a Network Policy, using the rule we created earlier:

CREATE OR REPLACE NETWORK POLICY IpRangePolicy
    ALLOWED_NETWORK_RULE_LIST = ('IpRangeRule'),
    COMMENT = 'Limits Snowflake access to certain IP addresses';

You can use ALTER NETWORK RULE and ALTER NETWORK POLICY if you wish to make changes to the rule or policy.

Activating Network Policies

An account can only have one active network policy at a time. Using SQL, you activate a policy like this:

ALTER ACCOUNT SET NETWORK_POLICY = IpRangePolicy;

Likewise, a user account can also only have a single network policy activated at any one time. The SQL is strikingly similar to the account SQL:

ALTER USER mike SET NETWORK_POLICY = IpRangePolicy;

With a security integration, you can specify the NETWORK_POLICY parameter to set the appropriate network policy, or you can use the ALTER statement.

ALTER SECURITY INTEGRATION integration_name SET NETWORK_POLICY = IpRangePolicy;

Managing Network Policies

To view all network policies in your account, run this command:

SHOW PARAMETERS LIKE 'network_policy' IN ACCOUNT;

If you want to view the rules, you can run:

SHOW NETWORK RULES;

Finally, you might want to check which Network Policies are active. As we've seen, each object type can only have one active policy at any one time. You have to use Snowsight to do this, by opening the Network Policies page and filtering on the Status field.

Summary

This is the first blog post covering security in Snowflake, and we've taken a look at what Network Policies and Network Rules can do for us. Policies and Rules give us a great combination, allowing us to protect our Snowflake accounts, users and security integrations. As a cloud-only system, Snowflake takes security very seriously (as it should!), so we'll delve further into other security options in future posts.

Page top