---
title: "Snowflake Setup"
slug: "snowflake-setup"
updated: 2026-05-24T15:46:37Z
published: 2026-05-24T15:46:37Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plainid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Snowflake Setup

Following is a set of prerequisites and instructions to support SaaS Authorization Management for Snowflake:

## Prerequisites

### Default PlainID User Role

The user assigned to PlainID for connecting to Snowflake (referred to as the POP user) must have sufficient privileges to manage all Orchestration-related operations. We recommend creating a dedicated PLAINID role and assigning it as the default role for the POP user. This role will also act as the owner of all Snowflake policies created from PlainID when operating in Manage Mode.

PlainID Role

Ensure that the **PLAINID role is the default role** for the User.

#### Required Privileges for LEARN Mode

To use LEARN mode, users must be granted the following privileges in Snowflake:

| Privilege | Purpose |
| --- | --- |
| `APPLY MASKING POLICY` | Grants the ability to view **Masking Policies** |
| `APPLY ROW ACCESS POLICY` | Grants the ability to view **Row Access Policies** |
| Integration | Grants visibility of the current IDP `USAGE`: When IDP is using **SCIM** `OWNERSHIP`: When IDP is using **SAML2** or **Oauth** |
| Database: `USAGE` | Grants visibility of database objects like **schemas** or **tags**. * **Required if granting the Schema: `USAGE` privilege** |
| Schema: `USAGE` | Grants visibility of schema objects like tables or tags. * **Required if granting the Table: `SELECT` privilege** **Privilege Options**: - Option 1: Grant a privilege on individual schemas - Option 2: Grant privileges on *all existing schemas* in the database (recommended) *Note: `Usage` can also be automated to grant privileges on every **future** schema created in the database*. |
| Function: `USAGE` | ***Optional*** If you want to manage a Policy using UDF, the `USAGE` privileges **must** be granted for that specific function. |
| `EVOLVE SCHEMA` | Grants visibility for tables, Iceberg Tables, and columns within the schema, including future tables. The schema **must** contain **at least** one table or View. *Note: In cases when a table or View is used with a select expression in the Policy, the `SELECT` table/View/Iceberg Table privilege **must** be granted for that specific table/View. **Example**: `GRANT SELECT ON ICEBERG TABLE` |
| Warehouse: `USAGE` | Grants access to a warehouse to run queries. |

#### Additional Required Privileges for MANAGE Mode

To use MANAGE mode, users must *also* be granted the following privileges in addition to LEARN mode privileges in Snowflake:

| Privilege | Purpose |
| --- | --- |
| `CREATE MASKING POLICY` | Grants the ability to create Masking Policies. **Privilege Options**: - Option 1: Grant privileges to create Masking Policies on **individual** schemas. - Option 2: Grant privileges to create Masking Policies on *all existing schemas* in the database (recommended). |
| `CREATE ROW ACCESS POLICY` | Grants the ability to create Row Access Policies. **Privilege Options**: - Option 1: Grant privileges to create Row Access Policies on **individual** schemas. - Option 2: Grant privileges to create Row Access Policies on *all existing schemas* in the database (recommended). |
| `APPLY MASKING POLICY` | Grants the ability to *set* **Masking Policies** on a table or view, in addition to setting a masking policy on a tag. This is a global privilege set at the account level. |
| `APPLY ROW ACCESS POLICY` | Grants the ability to *set* **Row Access Policies** on a table or view. This is a global privilege set at the account level. |

*Note: Ensure that you create a new Masking or Row Access Policy for at least one schema.*

Policy Ownership

To manage Policies in Snowflake, a user **must have the Policy ownership role**. To enable PlainID to manage **existing, discovered policies**, we recommend that existing Policy ownership roles are connected to the PlainID default Role, so that it inherits ownership. You also have the option to change the ownership of existing policies to the PlainID default role.

## Creating a Snowflake Policy Orchestration Point

After setting up a user with all the required privileges for Snowflake, you can now create a Snowflake Policy Orchestration Point (POP).

Ensure that you have an [Orchestration Workspace](/v1/docs/managing-workspaces) before continuing. You can learn how to **create a Snowflake POP** in [Managing POPs](/v1/docs/managing-pops) and how to **switch between modes** in [Orchestration Workspace](/v1/docs/orchestration-workspace).

### Snowflake Connection Settings

Snowflake credentials are used to connect to Snowflake resources through a Policy Orchestration Point (POP). To connect Snowflake with PlainID, enter the following **Connection Fields**:

| Connection Field | Description |
| --- | --- |
| Discover Views | If you wish to Discover Views, enable **Discover Views** to include Views along with Tables in the Discovery process. (**Default is false**) *Note: If a user has the relevant permissions to see Policies linked to Views, Views are discovered during the Discovery process, regardless of toggle setting.* |
| Authentication Method | **Key Pair** is automatically selected for Snowflake integration. See [Authentication Methods](/v1/docs/snowflake-setup#authentication-methods) section for information on **Key Pair Authentication** |
| Secret Store | Choose a Secret Store where your credentials are stored. The default is **PlainID Internal Vault**. Fields below are modified based on the chosen Store. For more information about **External Secret Stores** like **HashiCorp**, **Azure KeyVault**, or **AWS IAM for RDS or SM**, refer to [About Secret Stores](/v1/docs/about-secret-stores). |
| Compute Warehouse | The name of the Snowflake warehouse used for policy evaluation. |
| Username | The Snowflake account username with access to the warehouse and associated objects. |
| Secret Key | The Secret Key of the External Secret Store. Only for use with **[External Secret Stores](/v1/docs/about-secret-stores)**. |
| Port | The port used to connect to Snowflake (typically `443`). |
| Server | The full Snowflake server address (e.g., `xy12345.us-central-1.snowflakecomputing.com`). |

Connection Testing

You can test the connection to Snowflake directly from the PlainID Platform to ensure that the user has all the required privileges.

#### Key Pair Authentication

**Using Key Pair Authentication** Key pair authentication is a method used to verify identity in a secure manner by using public-key cryptography. Refer to the Snowflake documentation on [Using key-pair authentication](https://docs.snowflake.com/en/developer-guide/sql-api/authenticating#using-key-pair-authentication) for information.

If using `key-pair` authentication, the password field is swapped for a **Private Key** section with a button to **Import Secret Key**. Ensure that the key is uploaded before testing the connection. Only for use with the **PlainID Internal Store**. *Note: Passphrase is not supported.*

A Secret Key field appears if using [**External Secret Stores**](/v1/docs/about-secret-stores).

Existing POPs configured with Basic Authentication

For ***existing*** POPs using Basic Authentication. PlainID recommends migrating to Key Pair Authentication. Please note that once migrated, reverting to Basic Authentication is not supported.

PlainID currently supports Private Keys with the extensions .key, .pem, .txt, and .p8. Reach out to [PlainID support](https://plainid.atlassian.net/servicedesk/customer/portals) if you require additional extensions.