Snowflake Integration Setup

Honeydew requires access to Snowflake in order to operate. You have two options to set up Snowflake access - either using a central org-level connection parameters or map your individual Snowflake user credentials to Honeydew. If you would like to use a central org-level connection, it is advised to create a new dedicated Snowflake user for Honeydew integration. The following Snowflake connection parameters are required for Honeydew setup:

Account name
Username
Role
Warehouse

Authentication Methods

Honeydew supports the following authentication methods for Snowflake:

Key-pair authentication

This is the recommended method for org-level service accounts. For this method, you will need to provide a Private Key and possibly a Private Key Passphrase (if used).

Generate a key pair

MacOS
Windows

Generating an unencrypted private key can be done using the following command:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt

Generating an encrypted private key can be done using the following command:

openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key.p8

Generating the public key:

openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

Make sure the OpenSSH feature is enabled on your Windows machine. For the output folder we use Windows command line %userprofile% to direct to your user home folder. You can replace it with your preferred (existing) folder.

ssh-keygen -t rsa -b 2048 -m pkcs8 -f %userprofile%\rsa_key.p8

Convert the generated .pub file to a compatible format:

ssh-keygen -e -f %userprofile%\rsa_key.p8.pub -m pkcs8 > %userprofile%\rsa_key.pub

Store the generated keys in a secure location.

Assign the public key to a Snowflake user

To assign the public key to a Snowflake user, execute the following SQL command in Snowflake:

 -- Replace <HONEYDEW_USER> with the Snowflake user name and <PUBLIC_KEY> with the content of the rsa_key.pub file
ALTER USER <HONEYDEW_USER> SET RSA_PUBLIC_KEY='<PUBLIC_KEY>';

Exclude the public key delimiters in the SQL statement.

Configure the Snowflake connection in Honeydew

In Honeydew App settings page, configure the Snowflake connection using the Private Key and Private Key Passphrase (if used) from the previous step.

OAuth authentication

This is the recommended method for individual users credentials. Each user will need to connect to Honeydew using their own Snowflake OAuth credentials. For this method, you will need to create a new Snowflake OAuth integration and then provide a Client ID and Client Secret. When Snowflake OAuth is used, users can authorize their Honeydew credentials using SSO via Snowflake. If Snowflake is set up with SSO through a third-party identity provider, Honeydew users can use this method to log into Snowflake and authorize Honeydew credentials without any additional setup.

With OAuth, each Snowflake query runs as the Honeydew user who makes it, so organization-level API keys cannot run Snowflake queries. For automated jobs and integrations, use per-user API keys, which are enabled by support. The assigned user must have authorized Snowflake in Honeydew, and authorize again when the refresh token expires.

OAuth integration configuration

Locate the Honeydew redirect URI

You will need to provide the Honeydew redirect URI when creating the OAuth integration in Snowflake. The redirect URI can be found in the Honeydew App settings page under the Snowflake connection section. It should look like this (exact URI may vary based on your Honeydew deployment):

https://api.honeydew.cloud/oauth2callback

Save it for later use.

Create a Snowflake OAuth integration

To create a new OAuth integration in Snowflake, execute the following SQL command. You can find the complete documentation on creating an oauth integration here.In the following query, replace <REDIRECT_URI> with the Honeydew redirect URI you saved in the previous step. Replace <VALIDITY_IN_SECONDS> with the desired validity period for the refresh token - for example, 2592000 for 30 days. If not provided, the default is 7776000 (90 days).To let Honeydew use a role other than each user’s DEFAULT_ROLE - whether the role is set on the connection, on a workspace environment, or on a domain - include OAUTH_ANY_ROLE_MODE = ENABLE in the statement.If you are using secondary roles, please include OAUTH_USE_SECONDARY_ROLES = 'IMPLICIT' in the statement. If you would like to pre-authorize specific roles for OAuth authentication, provide the PRE_AUTHORIZED_ROLES_LIST parameter with a list of the actual role names you want to pre-authorize.For improved security, we recommend setting OAUTH_SINGLE_USE_REFRESH_TOKENS_REQUIRED = TRUE. This rotates the refresh token on every use, so a leaked token cannot be reused. See the Snowflake single-use refresh tokens documentation for details.

CREATE OR REPLACE SECURITY INTEGRATION HONEYDEW_OAUTH_INTEGRATION   -- Replace HONEYDEW_OAUTH_INTEGRATION with your desired integration name
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = '<REDIRECT_URI>'                 -- Replace with the Honeydew redirect URI
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = <VALIDITY_IN_SECONDS>  -- Replace with desired validity period in seconds
  OAUTH_SINGLE_USE_REFRESH_TOKENS_REQUIRED = TRUE       -- (Optional, recommended) Rotate the refresh token on each use for improved security
  NETWORK_POLICY = '<NETWORK_POLICY>'                   -- (Optional) Replace with the name of the network policy to use, if any
  PRE_AUTHORIZED_ROLES_LIST = ( '<role_name1>', ...)    -- (Optional) Replace with the list of roles that will be used for OAuth authentication
  OAUTH_ANY_ROLE_MODE = ENABLE                          -- (Optional) Required for non-default roles
  OAUTH_USE_SECONDARY_ROLES = IMPLICIT;                 -- (Optional) Required for secondary roles

Additional configuration options may be specified for the security integration as needed.

When defining a network policy for the OAuth integration, ensure that it allows access from the Honeydew IP addresses, in combination with any IP addresses that are used to access Snowflake from your SSO provider (e.g. Okta, etc..).

Only Snowflake users with the ACCOUNTADMIN role or a role with the global CREATE INTEGRATION privilege can execute this SQL command

Retrieve OAuth Client ID and Client Secret

Once the OAuth integration is created, you can configure the Snowflake connection in Honeydew. First, retrieve the Client ID and Client Secret for the OAuth integration you just created. You can do this by executing the following SQL command in Snowflake:

WITH
OAUTH_SECRETS as (
  select PARSE_JSON(
    system$SHOW_OAUTH_CLIENT_SECRETS('HONEYDEW_OAUTH_INTEGRATION')) as SECRETS_JSON     -- Replace HONEYDEW_OAUTH_INTEGRATION with your integration name
)
SELECT
  SECRETS_JSON:"OAUTH_CLIENT_ID"::string as CLIENT_ID,
  SECRETS_JSON:"OAUTH_CLIENT_SECRET"::string as CLIENT_SECRET
from
  OAUTH_SECRETS;

Configure the Snowflake connection in Honeydew

In Honeydew App settings page, configure the Snowflake connection using the Client ID and Client Secret from previous step.If the OAuth integration was created with OAUTH_ANY_ROLE_MODE, also check Integration allows any role. If either is missing, the issued token is bound to each user’s DEFAULT_ROLE and a connection that asks for another role fails even when the user has been granted that role.

User setup

Once Snowflake OAuth integration is configured, Honeydew users will be able to provide their credentials via OAuth. By clicking “Connect to Snowflake” in the Snowflake settings, users will be redirected to Snowflake to authorize with the configured SSO provider.

PAT (programmatic access tokens) authentication

For this method, you will need to provide a generated access token.

Generate a PAT in Snowflake

Follow the steps in the Snowflake documentation to create a PAT. Note the prerequisites required for PAT generation, such as:

Configure the PAT in Honeydew

In Honeydew App settings page, configure the Snowflake connection using the Access Token generated in Snowflake.

Password authentication

For this method, you will need to provide a password, and will likely be required to approve access via MFA.

Password authentication is not recommended for production use.

It is advised to use Key-pair authentication for Snowflake integration, when using an org-level service account, and to use OAuth authentication or PAT (programmatic access tokens) authentication for individual users credentials.It is strongly recommended to keep MFA enabled for any Snowflake users that are integrated with Honeydew.

The following Snowflake connection parameters are required to be able to deploy dynamic datasets to Snowflake:

Database - the database where Honeydew will deploy any dynamic datasets as views or tables
Schema - the schema where Honeydew will deploy any dynamic datasets as views or tables
Dev Database - the database where Honeydew will deploy any dynamic datasets as views or tables when working on a dev branch
Dev Schema - the schema where Honeydew will deploy any dynamic datasets as views or tables when working on a dev branch

Allowing Honeydew client IP addresses

If you have IP-based access restrictions in Snowflake, add the IP addresses displayed in the Snowflake connection screen in Honeydew App settings page to the “Allowed IP Addresses” list.

For the Honeydew Cloud deployment, the following IP addresses are used:

34.86.209.90
34.145.147.92

If you are using a private Honeydew deployment, the IP addresses will be different. You can find them in the Snowflake connection screen in Honeydew App settings page.

Snowflake Private Link

Honeydew supports Snowflake Private Link connectivity for customers who require private, secure connections that do not traverse the public internet. To configure Snowflake Private Link for your Honeydew deployment, contact support@honeydew.ai.

Permissions

Honeydew does not extract or store your data. It only reads schema metadata and executes SQL queries inside your Snowflake environment. You can find more security-related information here. If using an integration user deployment, the Honeydew integration user/role require the following permissions to operate:

USAGE on any databases and schemas which will be used as part of the semantic layer
SELECT on any tables/views which will be used as part of the semantic layer
CREATE TABLE, CREATE DYNAMIC TABLE, CREATE INTERACTIVE TABLE and CREATE VIEW on the database/schema where dynamic datasets will be deployed

Snowflake Cortex Requirements

Honeydew AI features, such as the Honeydew Analyst Bot, can use Snowflake Cortex to run LLM models. Honeydew calls the models through the Cortex REST API.

Snowflake User Access Requirements

Snowflake controls Cortex REST API access with two database roles. The role Honeydew runs with needs one of them:

SNOWFLAKE.CORTEX_REST_API_USER grants the Cortex REST API only, which is all Honeydew uses. Snowflake does not grant it to PUBLIC by default.
SNOWFLAKE.CORTEX_USER grants the Cortex AI features, including the REST API. Snowflake grants it to PUBLIC by default, so every role has it unless your organization revoked it.

Cortex calls run with the role set on the Honeydew Snowflake connection, or with the role of the workspace environment when it sets one. Roles set on a domain apply to data queries only. With OAuth, each user’s Cortex calls run with that user’s own session, whose role is the user’s DEFAULT_ROLE. If the integration was created with OAUTH_ANY_ROLE_MODE = ENABLE and Integration allows any role is checked in Honeydew, the session uses the connection or environment role instead. If that role lacks Cortex access, grant it the database role. Snowflake does not accept granting a database role to a user directly. With OAuth, grant it to each user’s default role, or to a role that all of those default roles inherit.

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_REST_API_USER TO ROLE HONEYDEW_USER_ROLE;

CORTEX_REST_API_USER restricts access only when the role does not also inherit CORTEX_USER. To use it as a fine-grained control, first revoke CORTEX_USER from PUBLIC. That removes inherited Cortex access from every role in the account, so grant CORTEX_USER to roles that still need other Cortex features before revoking it. See Setting up authorization.

To use Cortex Code, grant the following additional database role to each Cortex Code user’s role:

-- Required for all Cortex Code users
GRANT DATABASE ROLE SNOWFLAKE.COPILOT_USER TO ROLE <user_role>;

Model Access

Honeydew uses the following Cortex models:

claude-sonnet-5 - The main model used for AI-powered features
claude-haiku-4-5 - Generates conversation titles
llama3.1-8b - Used for simple and fast tasks

Any model you select in the Honeydew LLM Provider settings, or in an agent’s model field, is used as well. Snowflake controls model access with an application role per model, named CORTEX-MODEL-ROLE-<MODEL>. By default, Snowflake grants CORTEX-MODEL-ROLE-ALL to all roles, so every role can use every model. If your organization restricts model access, grant the Honeydew role an application role for each model:

GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-CLAUDE-SONNET-5" TO ROLE HONEYDEW_USER_ROLE;
GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-CLAUDE-HAIKU-4-5" TO ROLE HONEYDEW_USER_ROLE;
GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-LLAMA3.1-8B" TO ROLE HONEYDEW_USER_ROLE;

To list the model application roles in your account:

SHOW APPLICATION ROLES LIKE 'CORTEX-MODEL-ROLE-%' IN APPLICATION SNOWFLAKE;

For more details, see Control model access.

The list of the models used by Honeydew may change over time as new models are introduced or existing models are deprecated. Refer to the Honeydew release notes for any updates regarding Cortex model requirements.If you would like to be notified about such changes in advance, please contact support@honeydew.ai.

Model Availability

A model must also be available in the region of your Snowflake account. If a model is only available in another region or cloud provider, such as AWS for an account on Azure or GCP, enable cross-region inference. To check the current cross-region inference configuration:

SHOW PARAMETERS LIKE 'CORTEX_ENABLED_CROSS_REGION' IN ACCOUNT;

To enable cross-region inference, use one of the following commands: Enable across all regions:

ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'ANY_REGION';

Enable across specific regions (e.g., AWS_US, AWS_EU, etc.):

-- Enable cross-region inference to AWS_US
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_US';

-- Enable cross-region inference to AWS_EU
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_EU';

For more details about cross-region inference configuration, see the Snowflake Cortex Cross-Region Inference documentation.

Tracking Honeydew Queries in Snowflake

You can track and monitor queries executed by Honeydew in Snowflake using several methods. All queries from Honeydew include a standardized query tag that provides detailed information about the query context.

Query Tag Format

All Honeydew queries include a query tag with the following JSON format:

{
  "application": "Honeydew",
  "workspace": "some_workspace",
  "branch": "branch_name",
  "user": "username@example.com",
  "client": "Honeydew Server"
}

The query tag contains:

application: Always set to “Honeydew”
workspace: The Honeydew workspace name
branch: The Honeydew workspace branch being used (e.g., “dev”, “prod”)
user: The Honeydew user identifier (usually email address)
client: The client name, usually “Honeydew Server” for server-side operations

Tracking Methods

You can track Honeydew queries using any of the following approaches:

1. By User or Role

If you’re using dedicated Snowflake users or roles for Honeydew integration, you can filter queries by these identifiers in the SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY view.

2. By Warehouse

If you’re using dedicated warehouses for Honeydew operations, you can filter by warehouse name in the SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY view.

3. By Query Tag (Recommended)

The most comprehensive method is to filter by the Honeydew query tag. This approach works regardless of your Snowflake setup and allows you to track queries by workspace, branch, or user using the standardized query tag format.

Quick Start

Semantic Ecosystem

Modeling Reference

Context Layer

Management

Integrations

Security

Release Notes

Snowflake

Snowflake Integration Setup

Authentication Methods

Key-pair authentication

OAuth authentication

OAuth integration configuration

User setup

PAT (programmatic access tokens) authentication

Password authentication

Allowing Honeydew client IP addresses

Snowflake Private Link

Permissions

Snowflake Cortex Requirements

Snowflake User Access Requirements

Model Access

Model Availability

Tracking Honeydew Queries in Snowflake

Query Tag Format

Tracking Methods

1. By User or Role

2. By Warehouse

3. By Query Tag (Recommended)

​Snowflake Integration Setup

​Authentication Methods

​Key-pair authentication

​OAuth authentication

​OAuth integration configuration

​User setup

​PAT (programmatic access tokens) authentication

​Password authentication

​Allowing Honeydew client IP addresses

​Snowflake Private Link

​Permissions

​Snowflake Cortex Requirements

​Snowflake User Access Requirements

​Model Access

​Model Availability

​Tracking Honeydew Queries in Snowflake

​Query Tag Format

​Tracking Methods

​1. By User or Role

​2. By Warehouse

​3. By Query Tag (Recommended)

Snowflake Integration Setup

Authentication Methods

Key-pair authentication

OAuth authentication

OAuth integration configuration

User setup

PAT (programmatic access tokens) authentication

Password authentication

Allowing Honeydew client IP addresses

Snowflake Private Link

Permissions

Snowflake Cortex Requirements

Snowflake User Access Requirements

Model Access

Model Availability

Tracking Honeydew Queries in Snowflake

Query Tag Format

Tracking Methods

1. By User or Role

2. By Warehouse

3. By Query Tag (Recommended)