General Integrations

Assign the service principal to the Databricks workspace, then grant it the following privileges:

To configure the integration:

Create a BIGGY_READONLY role and a dedicated BIGGY_WH warehouse, then grant the role read-only access to each database that Biggy may query. 

In the code below, repeat the database grant lines for every database you want Biggy to see. Granting FUTURE keep new objects readable as your schema evolves.

CREATE ROLE IF NOT EXISTS BIGGY_READONLY;

-- Dedicated XS warehouse keeps Biggy's compute cost bounded and visible.
CREATE WAREHOUSE IF NOT EXISTS BIGGY_WH
  WAREHOUSE_SIZE = XSMALL AUTO_SUSPEND = 60 AUTO_RESUME = TRUE INITIALLY_SUSPENDED = TRUE;
GRANT USAGE ON WAREHOUSE BIGGY_WH TO ROLE BIGGY_READONLY;

-- Repeat per database Biggy should see. FUTURE grants keep new objects readable.
GRANT USAGE ON DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT USAGE ON ALL SCHEMAS IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON ALL TABLES IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON ALL VIEWS IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON FUTURE TABLES IN DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT SELECT ON FUTURE VIEWS IN DATABASE <db> TO ROLE BIGGY_READONLY;

Create the BIGGY_SVC service user and grant it the read-only role. 

CREATE USER IF NOT EXISTS BIGGY_SVC
  TYPE = SERVICE
  DEFAULT_ROLE = BIGGY_READONLY
  DEFAULT_WAREHOUSE = BIGGY_WH
  COMMENT = 'Biggy read-only integration user';
GRANT ROLE BIGGY_READONLY TO USER BIGGY_SVC;

-- Account-side runaway-query bound (Biggy also enforces its own timeout).
ALTER USER BIGGY_SVC SET STATEMENT_TIMEOUT_IN_SECONDS = 300;

The statement timeout sets an account-side bound on runaway queries. Biggy also enforces its own timeout.

Generate an RSA key-pair locally, then register the public key on the service user. 

Save this key somewhere referenceable. When you configure the integration, you will paste the full .p8 private key contents, including the BEGIN and END lines, into the Private Key (PEM) field. 

Key-pair credentials do not expire, and Biggy signs a short-lived JWT for each request. To rotate, generate a fresh pair, run ALTER USER BIGGY_SVC ROTATE KEY PAIR BIGGY_KEY PUBLIC_KEY = '<new_public_key_body>', and update the Private Key field in Biggy. The old key stays valid for 24 hours by default.

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out biggy_snowflake_key.p8 -nocrypt
openssl rsa -in biggy_snowflake_key.p8 -pubout -out biggy_snowflake_key.pub

-- Paste the .pub contents WITHOUT the BEGIN/END lines:
ALTER USER BIGGY_SVC ADD KEY PAIR BIGGY_KEY PUBLIC_KEY = '<public_key_body>';

A Programmatic Access Token (PAT) is simpler to issue, but it expires (365-day maximum), and Snowflake requires the service user to sit under a network policy that allows Biggy's egress IPs. 

The following SQL creates a dedicated BIGGY_ADMIN namespace for the network objects, builds the network rule and policy, applies the policy to the service user, and issues the token. 

Copy the token secret when Snowflake displays it and paste it into the Programmatic Access Token field in Biggy.

-- PATs require the service user to sit under a network policy.
-- Network rules are schema-level objects: create one in a dedicated Biggy namespace and
-- reference its FULLY QUALIFIED name from the account-level policy (unqualified names depend
-- on the worksheet's current database/schema and fail on a fresh session).
-- CREATE OR ALTER is the idempotent form (CREATE NETWORK RULE has no IF NOT EXISTS).
-- Re-running the rule/policy lines REPLACES VALUE_LIST and ALLOWED_NETWORK_RULE_LIST with
-- Biggy's current egress IPs; these objects are Biggy-owned -- do not share them.
CREATE DATABASE IF NOT EXISTS BIGGY_ADMIN;
CREATE SCHEMA IF NOT EXISTS BIGGY_ADMIN.NETWORK;
CREATE OR ALTER NETWORK RULE BIGGY_ADMIN.NETWORK.BIGGY_INGRESS_RULE
  TYPE = IPV4 MODE = INGRESS
  VALUE_LIST = ('3.131.207.50/32', '3.139.161.178/32', '3.132.123.188/32');
CREATE OR ALTER NETWORK POLICY BIGGY_ACCESS_POLICY
  ALLOWED_NETWORK_RULE_LIST = ('BIGGY_ADMIN.NETWORK.BIGGY_INGRESS_RULE');
ALTER USER BIGGY_SVC SET NETWORK_POLICY = 'BIGGY_ACCESS_POLICY';

-- Issue the PAT once. If BIGGY_PAT already exists, ADD fails -- rotate instead:
-- ALTER USER BIGGY_SVC ROTATE PROGRAMMATIC ACCESS TOKEN BIGGY_PAT;
ALTER USER BIGGY_SVC ADD PROGRAMMATIC ACCESS TOKEN BIGGY_PAT
  ROLE_RESTRICTION = 'BIGGY_READONLY' DAYS_TO_EXPIRY = 365;

To refresh Biggy's egress IPs, re-run only the network-rule and policy lines. Do not re-run ADD PROGRAMMATIC ACCESS TOKEN if BIGGY_PAT already exists. Rotate it instead with ALTER USER BIGGY_SVC ROTATE PROGRAMMATIC ACCESS TOKEN BIGGY_PAT, then update the token in Biggy.

If your account has semantic views or Cortex Search services, you can grant them to the BIGGY_READONLY role. Once granted access, Biggy discovers and uses them automatically, with no extra configuration.

Grant CORTEX_ANALYST_USER for REST access, then add per-view or per-service grants as needed.

-- Cortex Analyst REST access for the role (SNOWFLAKE.CORTEX_USER also works, but is broader):
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_ANALYST_USER TO ROLE BIGGY_READONLY;

-- Per semantic view: SELECT to query (owner's rights cover the base tables),
-- REFERENCES so discovery can inspect the structure.
GRANT SELECT, REFERENCES ON SEMANTIC VIEW <db>.<schema>.<view> TO ROLE BIGGY_READONLY;

-- Per Cortex Search service (the role also needs USAGE on its database and schema):
GRANT USAGE ON DATABASE <db> TO ROLE BIGGY_READONLY;
GRANT USAGE ON SCHEMA <db>.<schema> TO ROLE BIGGY_READONLY;
GRANT USAGE ON CORTEX SEARCH SERVICE <db>.<schema>.<service> TO ROLE BIGGY_READONLY;

Biggy reaches Snowflake over the public account URL from three egress IPs: 3.131.207.50, 3.139.161.178, and 3.132.123.188. If your account enforces network policies, allow these IPs. The Programmatic Access Token SQL above does this for you.

PrivateLink-only accounts can route through a Biggy Remote Connection instead of the public URL. Set Deployment Type to On-Prem on the instance, save, then assign the instance to a relay client under Remote Connections in the Configuration area. Use your PrivateLink account URL.