> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server. # Snowflake > Connect your Snowflake data warehouse to Kumo using the Direct Connector or Secure Data Sharing. #### Direct Connector Kumo can directly connect to your Snowflake data warehouse. This connection method ensures that all data stays in your control and preserves the integrity and security of your environment. This connection method is recommended for production use. 1. To set up a new Snowflake direct connection, click on **Connectors** in the left-hand column, followed by the **Configure Connector** button on the "Connectors" page. 2. On the "New Connector" window, provide a name for your new Snowflake connector and click the Snowflake button. The configuration settings for connecting to your Snowflake data warehouse will immediately appear below. 3. Provide the following details in the Snowflake Warehouse section to connect your Snowflake data warehouse: * **Account Identifier** - The account identifier uniquely identifies your Snowflake account. This should be provided as `ORGNAME-ACCOUNT_NAME`. The `ORGNAME` and `ACCOUNT_NAME` can be retrieved for your Snowflake account using the instructions [here](https://docs.snowflake.com/en/user-guide/admin-account-identifier#finding-the-organization-and-account-name-for-an-account). * **Database** - The Snowflake database where the input relational data exists. The user who is authenticating must have a `DEFAULT_ROLE` with `USAGE` privileges to this database. * **Warehouse** - The warehouse that will be used to read and process data in Snowflake. The user who is authenticating must have a `DEFAULT_ROLE` with `USAGE` privileges to this warehouse. * **Schema Name** - The schema under the Database where the input tables are to be loaded from. Make sure that the user who is authenticating has a role that has `USAGE` and `SELECT` privileges on the schema. If predictions are to be written back using this connector, the user's `DEFAULT_ROLE` should have `CREATE TABLE` privilege on this schema. * **User** - The username that you want to use to connect to Snowflake. * **Password** - The password of the user who is connecting the connector. Click on the **Done** button to save your new Snowflake connector. ![Add Connector page with Snowflake selected as the connector type](https://fdr-prod-docs-files-public.s3.us-east-1.amazonaws.com/nvidia-sdgm.docs.buildwithfern.com/2381ee281c0c6179cf992d69d28097135df1fe7a515b1564f808aca994e5074d/img/kumo3/add-connector-snowflake.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIA6KXJSKKNFOCF7G4B%2F20260912%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260912T195243Z&X-Amz-Expires=604800&X-Amz-Signature=9f9577bb89320957b9f091a57383bc3c2212659e9237e681e9037594cab758f1&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject) ### Using key-pair authentication For Snowflake accounts with MFA or SSO enabled, Kumo requires the use of public key authentication, either with a regular user account that has a key-pair setup in addition to a username and password, or with a “service” account which does not have a username and password login (refer to [CREATE USER](https://docs.snowflake.com/en/sql-reference/sql/create-user) for creating service accounts). To use Kumo with key-pair authentication, first generate a private key (encrypted or unencrypted) and then a corresponding public key. Refer to [Snowflake documentation](https://docs.snowflake.com/en/user-guide/key-pair-auth) on how to do this with OpenSSL. Next, assign the public key to an existing Snowflake user with the command (excluding delimiters from the key): `ALTER USER example_user SET RSA_PUBLIC_KEY='MIIBIjANBgkqh...';` Note that this must be done by the owner of the user or a user with `SECURITYADMIN` role or higher. Alternatively, create a new user with the `RSA_PUBLIC_KEY` field set (refer to [CREATE USER](https://docs.snowflake.com/en/sql-reference/sql/create-user)). When a new user or service user is created with the key-pair authentication configured, this user’s role must also be assigned the necessary privileges to access the data (refer to [below](/snowflake-connector#minimum-privileges-required-for-the-connecting-user) for the minimum required privileges to connect data in Kumo). Now instead of “User” and “Password” credentials, key-pair authentication can be used to configure a Snowflake connector in Kumo. On the New Connector window, toggle on “Key-Pair Authentication” and enter the “User” and “Private key”. If the “Private key” is encrypted, enter the “Key Passphrase”; otherwise the passphrase can be left blank. The private key should be entered with line breaks preserved. Click on the **Done** button to save your new Snowflake connector. ### Minimum privileges required for the connecting user When connecting to Snowflake, the user's `DEFAULT_ROLE` is used by Kumo. To check the default role of the user, run `DESCRIBE USER ` in Snowflake. The following is the minimum set of privileges required to create a Snowflake connector to read data into Kumo and write predictions back. The default role of the user (`user_role` in the commands below) used to create the Snowflake Connector must be granted these privileges to successfully connect your Snowflake data to Kumo. The commands below assume you are connecting a Database called `customer_db` and schema `customer_schema` in that Database using a warehouse `customer_warehouse`. **`SQL`** ```Text SQL -- In the following, replace user_role with the actual DEFAULT_ROLE of the user. -- You can get the DEFAULT_ROLE of the user by running DESCRIBE USER -- Grant usage privilege on the database GRANT USAGE ON DATABASE customer_db TO ROLE user_role; -- Grant usage/monitor privileges on the schema -- Also grant the privilege to create regular and materialized views in the schema GRANT USAGE, MONITOR, CREATE VIEW, CREATE MATERIALIZED VIEW ON SCHEMA customer_db.customer_schema TO ROLE user_role; -- Grant read-only privileges on all tables in the schema -- REFERENCES is needed to get table metadata by querying the information schema GRANT SELECT, REFERENCES ON ALL TABLES IN SCHEMA customer_db.customer_schema TO ROLE user_role; -- [Optional] Grant read-only privileges on all future tables created in the schema GRANT SELECT, REFERENCES ON FUTURE TABLES IN SCHEMA customer_db.customer_schema TO ROLE user_role; -- Privilege to create tables and views in the schema to write back predictions. GRANT CREATE TABLE ON SCHEMA customer_db.customer_schema TO ROLE user_role; -- Privilege to drop tables in the schema to write back predictions. GRANT DROP TABLE ON SCHEMA customer_db.customer_schema TO ROLE user_role; -- Privilege to use a warehouse GRANT USAGE ON WAREHOUSE customer_warehouse TO ROLE user_role; ``` ### VPN-Protected Snowflake Instances If your Snowflake instance is behind a VPN, you will need to add the Kumo Cloud Network gateway to your allowlist. More information can be found [here](https://docs.snowflake.com/en/user-guide/network-policies). ### Snowflake Data Warehouse Sizing Kumo recommends the following data warehousing size guidelines, based on the total data size of your largest table: | Largest Table Size | Warehouse size (SaaS) | | ------------------ | --------------------- | | Up to 10 GB | Small | | Up to 50 GB | Large | | Up to 100 GB | Large | | Up to 1 TB | 4x-Large | #### Secure Data Sharing Before sharing data with Kumo, ensure the following: **1. Provider Sharing is Enabled** * Log into your Snowflake account. * Navigate to **Account** > **Policies**. * Ensure **Provider Sharing** is set to `Enabled`. If not, activate it. For more about Secure Data Sharing, refer to [Snowflake's official documentation](https://docs.snowflake.com/en/user-guide/data-sharing-intro). **2. Identify Your Snowflake Account's Region** Data sharing is most straightforward when provider and consumer accounts are in the same Snowflake region. If they are in different regions, the data provider needs to use Snowflake's "Data Replication" to replicate the data to the region where the consumer account resides before sharing. Kumo does not recommend Data Replication. Kumo has accounts in most of the global regions. Access the Snowflake web interface - your account’s region is displayed in the top right corner, next to the account name (e.g., `us-west-2`). Share with Kumo’s account in the matching region, as secure sharing is only allowed between accounts in the same cloud and region. ### Identify Your Snowflake Account Edition The "Secure Data Sharing" feature is available in all editions of Snowflake, including Standard, Enterprise, Business Critical, and Virtual Private Snowflake (VPS). An account using the Standard edition can share data with an account using the Enterprise edition and vice versa. **An account on the Business Critical edition is restricted from sharing data with an account on a lower edition.** **Role Permissions** The role used to create the share must have the necessary permissions on the objects being shared. You will not incur any additional storage costs for the shared data. When querying your shared data, Kumo incurs the computational costs. ## Creating a Snowflake Secure Share for Kumo You can use Snowflake Secure Shares to share data with Kumo. This allows you to share the following Database objects (refer to [https://docs.snowflake.com/en/user-guide/data-sharing-intro](https://docs.snowflake.com/en/user-guide/data-sharing-intro) for more details): * Tables * External tables * Secure views * Secure materialized views **1. Establishing the Share** Create a share: Use the `CREATE SHARE` command to create an empty share. For example: **`SQL`** ```Text SQL CREATE SHARE KUMO_SHARE; ``` Use the `GRANT … TO SHARE` command to add a database to the share and then selectively grant access to specific database objects (schemas, tables, and secure views) to the share. For example: **`SQL`** ```Text SQL GRANT USAGE ON DATABASE my_database TO SHARE kumo_share; GRANT SELECT ON TABLE my_database.my_table TO SHARE kumo_share; GRANT USAGE on schema my_database.myschema TO SHARE kumo_share; GRANT SELECT on table my_database.myschema.shared_table TO SHARE kumo_share; ``` **Notes:** 1. Only users with the `CREATE SHARE` privilege can create a secure share. Only the `ACCOUNTADMIN` has this privilege by default and must be granted to the role creating the secure share for Kumo. Refer to the [Snowflake documentation](https://docs.snowflake.com/en/sql-reference/sql/create-share#access-control-requirements) for more details. 2. Only Secure views can be shared using Snowflake Secure shares. Do not use **SELECT(\*)** when creating Snowflake views, as this can break if your source tables change. Whenever possible, you should connect your raw tables to Kumo and avoid Snowflake Views. **2. Sharing with Kumo** Add KUMO account (select east or west locator based on where your account is located) access to the share. Use the `ALTER SHARE` command to add one or more accounts access to the share. For example: **`SQL`** ```Text SQL ALTER SHARE KUMO_SHARE_TEST ADD ACCOUNTS=.; ``` Refer to the region your Snowflake account is in and use the appropriate Kumo account from this table below: | Cloud | Region | Locator | Org Name | Account Name | Edition | | ----- | -------------------- | -------- | -------- | -------------------- | ----------------- | | AWS | US West (Oregon) | YRB86739 | LFWGWBP | ZXA66432 | Business Critical | | AWS | US West (Oregon) | YRB86739 | LFWGWBP | KUMOUSWEST | Enterprise | | AWS | US East (N.Virginia) | IUB99615 | LFWGWBP | KUMO\_US\_EAST1 | Enterprise | | AWS | US East (Ohio) | RR45566 | LFWGWBP | KUMO\_US\_EAST\_OHIO | Enterprise | | AWS | US East (N.Virginia) | CZB55260 | LFWGWBP | KUMOUSEAST1BC | Business Critical | Once the region matches, share the established share with the respective Kumo Snowflake account. --- ## Security Considerations The following are key security considerations for understanding Kumo's access mechanism to Snowflake instances. 1. **Database Creation on Kumo's End** - Kumo will generate a new database from the share received. It will serve as the central space for EDA and PoV operations. 2. **Defining Access Roles** - A unique ROLE will be crafted within Kumo's database to guarantee secured data access. 3. **Allocating Exclusive Access** - Access is provided only to Kumo's designated Point of Contact, safeguarding your data. --- ## Monitoring Access and Activities * **Queryable Audit Trails**: Use `SHARE_USAGE`, `QUERY_HISTORY`, and `LOGIN_HISTORY` views within Snowflake to review Kumo's interactions. * **Role-Based Access Control**: Monitor the unique ROLE for Kumo to ensure compliant data access. * **Data Manipulation Monitoring**: Use Snowflake's query history to document any changes made by Kumo. * **Scheduled Audits**: Regularly check logs, role permissions, and shares to guarantee data safety and accuracy. Contact your Kumo support if you would like to export your predictions back into your Snowflake instance.