> ## Documentation Index > Fetch the complete documentation index at: https://kumo.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Snowflake > Kumo offers three ways to connect to your Snowflake data warehouse. Click the tab below to learn more. - Snowflake Direct Connector - Snowflake Secure Data Sharing - Snowflake Native App 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 way of connection is recommended for running Kumo in production. 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. ### 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 (see [CREATE USER](https://docs.snowflake.com/en/sql-reference/sql/create-user) for creating service accounts). To use Kumo with a key-pair authorization, first generate a private key (encrypted or unencrypted) and then a corresponding public key. See [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 (see [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 (see [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 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` ```Text SQL theme={null} -- 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 and views in the schema to write back predictions. GRANT DROP TABLE ON SCHEMA IDENTIFIER($SCHEMA_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); -- 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 | Before initiating the sharing process with Kumo, please 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, please see [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 will be displayed in the top right corner, next to the account name (e.g., `us-west-2`). Remember to share with Kumo’s account in the corresponding region because secure share is only allowed with 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). Thus, 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 (see [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: ```Text SQL theme={null} 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: ```Text SQL theme={null} 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. See 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: ```Text SQL theme={null} 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. Kumo connects to your Snowflake data warehouse using a Snowflake Connector. Creating a Snowflake connector in Kumo requires the following steps: ### Step 1: Grant the privileges required The following is the minimum set of privileges that should be granted to the Kumo Snowflake app to successfully create a Snowflake connector. **Note** 1. The following commands should be run by a user who has `OWNERSHIP` or `WITH GRANT OPTION` privileges on the objects (warehouse, database, schema and tables) being granted access to. 2. The objects used in the commands (warehouse, database, and schema) must be the same as those used to create the connector (in Step 2 below). 3. See Warehouse sizing table [below](/spcs-snowflake-connector#snowflake-data-warehouse-sizing) for the size of the warehouse to use. ```Text SQL theme={null} -- In the following, replace KUMOAPP_NAME, DB_NAME, SCHEMA_NAME and WAREHOUSE_NAME with -- those that will be used to build models with Kumo. SET KUMOAPP_NAME='KUMO'; SET DB_NAME=''; SET SCHEMA_NAME='.'; SET WAREHOUSE_NAME=''; GRANT USAGE ON WAREHOUSE IDENTIFIER($WAREHOUSE_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); GRANT USAGE ON DATABASE IDENTIFIER($DB_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); GRANT USAGE ON SCHEMA IDENTIFIER($SCHEMA_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); GRANT SELECT, REFERENCES ON ALL TABLES IN SCHEMA IDENTIFIER($SCHEMA_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); GRANT SELECT, REFERENCES ON ALL VIEWS IN SCHEMA IDENTIFIER($SCHEMA_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); GRANT SELECT, REFERENCES ON ALL MATERIALIZED VIEWS IN SCHEMA IDENTIFIER($SCHEMA_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); GRANT CREATE TABLE ON SCHEMA IDENTIFIER($SCHEMA_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); GRANT DROP TABLE ON SCHEMA IDENTIFIER($SCHEMA_NAME) TO APPLICATION IDENTIFIER($KUMOAPP_NAME); ``` ### Step 2: Creating the Snowflake connector 1. To set up a new Snowflake connector, click on **Connectors** in the left-hand column, followed by the **Configure Connector** button on the "Connectors" page. 2. On the "Snowflake Connector" window, provide a name for your Snowflake connector and add the following connection details. The necessary privileges (described [above](/spcs-snowflake-connector#step-1-grant-the-privileges-required)) must be granted to the Kumo application before this step. * **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 (same as the one in Step 1). * **Warehouse** - The warehouse that will be used to read and process data in Snowflake (same as the one in Step 1). * **Schema Name** - The schema under the Database where the input tables are to be loaded from (same as the one from Step 1 but should not be prefixed with the Database name). Click on the **Done** button to save your new Snowflake connector. ### Snowflake Data Warehouse Sizing Kumo recommends the following data warehousing sizes for the Snowflake Native app based on the size of your largest table. | Largest Table Size | Snowflake warehouse Size | | --------------------------------------- | ------------------------------------------------------- | | Up to 10 GB (10s of millions of rows) | Medium | | 10 to 100 GB (100s of millions of rows) | Large | | Greater than 100GB | Currently not supported in Kumo's Snowflake Native app. |