> For the complete documentation index, see [llms.txt](https://documentation.immuta.com/saas/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.immuta.com/saas/configuration/integrations/snowflake/how-to-guides/connect-snowflake.md).

# Register a Snowflake Connection

{% hint style="info" %}
**Preview documentation for upcoming feature**

This page currently reflects the UI that users will see in future updates.
{% endhint %}

#### **Requirements**

* `APPLICATION_ADMIN` Immuta permission
* The Snowflake user registering the connection and running the script must have the following privileges:
  * `CREATE DATABASE ON ACCOUNT WITH GRANT OPTION`
  * `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
  * `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`

## Set up the Immuta system account

Complete the following actions in Snowflake:

1. [Create a new user in Snowflake to be the Immuta system account](https://docs.snowflake.com/en/sql-reference/sql/create-user). Immuta will use this system account continuously to orchestrate Snowflake policies and maintain state between Immuta and Snowflake.
2. [Create a Snowflake role](https://docs.snowflake.com/en/sql-reference/sql/create-role) with a minimum of the following privileges:
   * `USAGE` on all databases and schemas with registered data sources.
   * [`REFERENCES` on all tables and views registered in Immuta.](#user-content-fn-1)[^1]
   * [`SELECT` on all tables and views registered in Immuta](#user-content-fn-2)[^2].
3. [Grant the new Snowflake role](https://docs.snowflake.com/en/sql-reference/sql/grant-role) to the system account you just created.

## Register a connection

To register a Snowflake connection, follow the instructions below.

1. Click <i class="fa-database">:database:</i> **Data** and select the **Connections** tab in the navigation menu.
2. Click the **+ Add Connection** button.
3. Select the Snowflake data platform tile.
4. Enter the connection information:
   * **Display Name**: The display name represents the unique name of your connection and will be used as prefix in the name for all data objects associated with this connection. It will also appear as the display name in the UI and will be used in all API calls made to update or delete the connection. Avoid the use of periods (`.`) or [restricted words](#user-content-fn-3)[^3] in your connection name.
   * **Host**: The URL of your Snowflake account.
   * **Port**: Your Snowflake port.
   * **Warehouse**: The warehouse the Immuta system account user will use to run queries and perform Snowflake operations.
   * **Role**: Enter the role with the [listed privileges](#set-up-the-immuta-system-account).
   * **Immuta Database**: The new, empty database for Immuta to manage. The script in the last step of registering the connection will create this database. This is where system views, user entitlements, row access policies, column-level policies, procedures, and functions managed by Immuta will be created and stored.
5. Select an authentication method from the dropdown menu and enter the authentication information for the [Immuta system account you created](#set-up-the-immuta-system-account).

<details>

<summary>Username and password</summary>

{% hint style="info" %}
[**Not recommended**](https://docs.snowflake.com/en/user-guide/security-mfa-rollout?mkt_tok=MjUyLVJGTy0yMjcAAAGZu09Et_t5L994WaIvRvYZpAk-JOLFLHEkGfyJN2h85O_TaxTTXefu85qCiUxOO4CmgNx6eMMiPzwJUIwKNNgqMz8ICtR7CchZKPbZ9oN-cIaE3oqTfg#label-security-mfa-milestone-service-new)
{% endhint %}

Enter the username and password.

</details>

<details>

<summary>OAuth M2M (Client Secret)</summary>

1. Fill out the **Client ID**, which is the subject of the generated token. It is also known as `sub` (subject).
2. Fill out the **Authority URL**, which is the authority URL of your identity provider.
3. Fill out the **Scope**, which is the scope of operations and roles allowed by the secret. Use `session:role-any`.
4. Fill out the **Client Secret**, which is the client secret Immuta will use to connect to your application.

</details>

<details>

<summary>OAuth M2M (Certificate)</summary>

1. Fill out the **Client ID**, which is the subject of the generated token. It is also known as `sub` (subject).
2. Fill out the **Authority URL**, which is the authority URL of your identity provider.
3. Fill out the **Scope**, which is the scope of operations and roles allowed by the secret. Use `session:role-any`.
4. Enter the **Certificate Thumbprint**. This identifies the corresponding key to the token and is often abbreviated as `x5t` or is called `kid` (key identifier).
5. Opt to fill out the **Resource** field with a URI of the resource where the requested token will be used.
6. Upload the **Private Key**, which is the client certificate that is used to sign the authorization request.

</details>

<details>

<summary>Key Pair (Unencrypted)</summary>

1. Complete the **Username** field. This user must be [assigned the public key in Snowflake](https://docs.snowflake.com/en/user-guide/key-pair-auth#assign-the-public-key-to-a-snowflake-user).
2. Click **Private Key**, and upload the Snowflake private key pair file.

</details>

<details>

<summary>Key Pair (Encrypted)</summary>

1. Complete the **Username** field. This user must be [assigned the public key in Snowflake](https://docs.snowflake.com/en/user-guide/key-pair-auth#assign-the-public-key-to-a-snowflake-user).
2. Click **Private Key**, and upload the Snowflake private key pair file.
3. When using an encrypted private key, enter the **Password**.

</details>

6. Click **Next**.
7. Configure the **Policy** settings:
   1. Opt to enable **Impersonation**. If you enable it, enter the **Impersonation Role** that will be used to impersonate other users in Snowflake.
   2. Opt to [exclude specific users from policy](/saas/configuration/integrations/snowflake/reference-guides/snowflake-overview.md#excepted-roles-users) by adding them to the **Exclude User Group Pattern**. This field cannot be changed after the connection is created.
8. Click **Next**.
9. Opt to **Enable Audit**.
10. Click **Next**.
11. Opt to **Enable Object Sync**, which will keep your connection objects up to date with your Snowflake environment.
    1. Select the **Start Time** for when the first object sync job will run each day.
    2. Select the **Run Frequency** to determine how frequently object sync will run each day.
    3. Opt to **Run Object Sync on Create** to create all the data objects for your connection. If you do not select this option, you must run object sync manually or wait for the scheduled object sync for your connection's data objects.
12. Click **Save connection**.
13. Copy the provided script and run it in Snowflake as a user with the privileges [listed in the requirements section](#requirements). Running this script grants the following privileges to the Immuta system account and creates the new Immuta database in Snowflake:
    1. `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
    2. `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`
    3. `APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION`
    4. `APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION`
14. Click **Validate Connection**.
15. If the connection is successful, click **Finish**. If there are any errors, check the connection details and credentials to ensure they are correct and try again.

[^1]: You must specify the Snowflake object type when granting `REFERENCES` on the table or view. For example, running `GRANT REFERENCES ON ALL TABLES` will grant this privilege to the standard table object type, but not to Iceberg tables or external tables. Instead, you would also have to run `GRANT REFERENCES ON ALL ICEBERG TABLES` and `GRANT REFERENCES ON ALL EXTERNAL TABLES`.

[^2]: Only required when using [identification](/saas/configuration/tags/data-discovery.md) or [specialized masking policies that require fingerprinting](/saas/govern/secure-your-data/authoring-policies-in-secure/data-policies/reference-guides/masking-matrix-functions.md#types-limited-to-snowflake).\
    \
    You must specify the Snowflake object type when granting `SELECT` on the table or view. For example, running `GRANT SELECT ON ALL TABLES` will grant this privilege to the standard table object type, but not to Iceberg tables or external tables. Instead, you would also have to run `GRANT SELECT ON ALL ICEBERG TABLES` and `GRANT SELECT ON ALL EXTERNAL TABLES`.

[^3]: Your display name cannot be any of the following words: `data`, `connection`, `object`, `crawl`, `search`, `settings`, `metadata`, `permission`, `sync`, `bulk`, and `upgrade`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://documentation.immuta.com/saas/configuration/integrations/snowflake/how-to-guides/connect-snowflake.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
