Connect Snowflake

Use a dedicated Snowflake service user, an RSA key pair, and a role that can read only the tables you choose. You need permission to create the user and grant access in Snowflake, plus owner or admin access in Kimpton.

Success check: After connecting, open Vault → Data Catalog and confirm that an expected table appears. Open it to check its columns and a sample preview. Kimpton catalogs table structure; it does not copy whole tables into the catalog. Table rows are read on demand within the granted scope.

Step 1 — Generate an RSA key pairCopy Anchor Link

On any machine with OpenSSL:

# Private key (unencrypted PKCS#8) — this goes into Kimpton's connect screen.
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out kimpton_snowflake_key.p8 -nocrypt

# Public key — this goes on the Snowflake service user (Step 2).
openssl rsa -in kimpton_snowflake_key.p8 -pubout -out kimpton_snowflake_key.pub

Keep kimpton_snowflake_key.p8 secret. You'll paste its contents into Kimpton once.

Step 2 — Create the read-only role, warehouse, and service userCopy Anchor Link

Run in a Snowflake worksheet. Replace the public-key body with the contents of kimpton_snowflake_key.pub (the lines between the BEGIN/END PUBLIC KEY markers, with the newlines removed).

USE ROLE ACCOUNTADMIN;

-- 1. A read-only role Kimpton will use.
CREATE ROLE IF NOT EXISTS KIMPTON_READ_ONLY;

-- 2. A small warehouse for metadata + sample-preview queries (or reuse an existing one).
--    This becomes the service user's default warehouse, so Kimpton never needs to pick one.
CREATE WAREHOUSE IF NOT EXISTS KIMPTON_WH
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;
GRANT USAGE ON WAREHOUSE KIMPTON_WH TO ROLE KIMPTON_READ_ONLY;

-- 3. The non-human service user. TYPE = SERVICE means no password / no MFA — key-pair only.
--    (On older Snowflake editions without TYPE = SERVICE, drop that line; a user with only
--     an RSA_PUBLIC_KEY and no password behaves the same for programmatic access.)
CREATE USER IF NOT EXISTS KIMPTON_SVC
  TYPE = SERVICE
  DEFAULT_ROLE = KIMPTON_READ_ONLY
  DEFAULT_WAREHOUSE = KIMPTON_WH
  RSA_PUBLIC_KEY = 'MIIBIjANBgkqh...paste the public key body here...IDAQAB';
GRANT ROLE KIMPTON_READ_ONLY TO USER KIMPTON_SVC;

Step 3 — Grant read-only access to only the tables you want Kimpton to seeCopy Anchor Link

This is how you control exposure. Kimpton's catalog shows only what KIMPTON_READ_ONLY can SELECT: nothing more. Grant at whatever granularity you want.

Whole database:

GRANT USAGE  ON DATABASE ANALYTICS               TO ROLE KIMPTON_READ_ONLY;
GRANT USAGE  ON ALL SCHEMAS IN DATABASE ANALYTICS TO ROLE KIMPTON_READ_ONLY;
GRANT SELECT ON ALL TABLES  IN DATABASE ANALYTICS TO ROLE KIMPTON_READ_ONLY;
GRANT SELECT ON ALL VIEWS   IN DATABASE ANALYTICS TO ROLE KIMPTON_READ_ONLY;
-- Include tables/views created later:
GRANT SELECT ON FUTURE TABLES IN DATABASE ANALYTICS TO ROLE KIMPTON_READ_ONLY;
GRANT SELECT ON FUTURE VIEWS  IN DATABASE ANALYTICS TO ROLE KIMPTON_READ_ONLY;

Or scope down to a single schema:

GRANT USAGE  ON DATABASE ANALYTICS                 TO ROLE KIMPTON_READ_ONLY;
GRANT USAGE  ON SCHEMA   ANALYTICS.PUBLIC          TO ROLE KIMPTON_READ_ONLY;
GRANT SELECT ON ALL TABLES    IN SCHEMA ANALYTICS.PUBLIC TO ROLE KIMPTON_READ_ONLY;
GRANT SELECT ON FUTURE TABLES IN SCHEMA ANALYTICS.PUBLIC TO ROLE KIMPTON_READ_ONLY;

To revoke exposure later, REVOKE the grant. The table disappears from Kimpton on the next refresh.

Step 4 — (Optional) Restrict access by IPCopy Anchor Link

If you enforce a network policy, get the current integration egress addresses from Kimpton support. Apply the policy to the service user, not the whole Snowflake account. See IP allowlist for Snowflake.

Step 5 — Connect in KimptonCopy Anchor Link

In Kimpton: Settings → Integrations → + Connection → Snowflake (or Vault → Data Catalog → + Connection → Snowflake). In the connect screen, provide:

• Account identifier — e.g. orgname-accountname or xy12345.us-east-1 (Snowsight → your name → Account → view the account identifier).
• User name — KIMPTON_SVC.
• Private key — the full contents of kimpton_snowflake_key.p8.

Kimpton verifies the connection with SHOW DATABASES and a bounded INFORMATION_SCHEMA query through the service role. This checks the key pair, role visibility, and default warehouse before activation, then cataloging starts automatically. Small accounts usually populate quickly; accounts with hundreds of databases are processed in bounded per-database pages and can take longer. New tables you grant later show up on the next scheduled refresh (no action needed).

TroubleshootingCopy Anchor Link

• Connection stays "Review"/won't activate — the service role can't run SHOW DATABASES or the warehouse-backed INFORMATION_SCHEMA probe, or the key pair doesn't match. Re-check RSA_PUBLIC_KEY, the matching private key, DEFAULT_ROLE, DEFAULT_WAREHOUSE, and warehouse USAGE.
• Catalog is empty after connecting — the role has no SELECT grants yet (Step 3), or the granted databases genuinely have no tables. Grants are the control surface.
• A table you expect is missing — confirm KIMPTON_READ_ONLY has SELECT on it (SHOW GRANTS TO ROLE KIMPTON_READ_ONLY;), then refresh the catalog.