Snowflake Setup

Connect Slateo to your Snowflake data warehouse using a dedicated service user with least-privilege access. This guide walks you through creating a user, role, and warehouse configuration, with key-pair authentication as the recommended direct-connect option supported by Slateo today.


Overview

Snowflake supports fine-grained access control through users, roles, and grants. This allows Slateo to securely access your data without broad write permissions. You can control access at the database, schema, or table level, configure dedicated compute resources for Slateo queries, and use a dedicated service user for non-human access.


Prerequisites

Before setting up the connection, ensure you have:

  • An active Snowflake account
  • ACCOUNTADMIN or SECURITYADMIN role to create users and roles
  • SYSADMIN role or higher to grant database and warehouse access
  • At least one database and schema with tables you want Slateo to access
  • A warehouse for query execution (or permissions to create one)

Quick start

Create a service user and attach a key pair

If you want the shortest reliable setup path, use the default Slateo names below and only change the warehouse/database/schema values later in the guide.

This quick start:

  • creates a dedicated Snowflake service user
  • creates a dedicated role
  • grants the role to the user
  • generates a key pair locally
  • formats the public key exactly the way Snowflake expects it

1. Create the service user and role in Snowflake

Run this SQL in a Snowflake worksheet in Snowsight:

USE ROLE SECURITYADMIN;

CREATE ROLE IF NOT EXISTS SLATEO_READONLY_ROLE
  COMMENT = 'Read-only role for Slateo data analytics';

USE ROLE USERADMIN;

CREATE USER IF NOT EXISTS SLATEO_READONLY
  TYPE = SERVICE
  DEFAULT_ROLE = SLATEO_READONLY_ROLE
  COMMENT = 'Slateo service user';

USE ROLE SECURITYADMIN;

GRANT ROLE SLATEO_READONLY_ROLE TO USER SLATEO_READONLY;

2. Verify the user exists

Run:

USE ROLE USERADMIN;
SHOW USERS LIKE 'SLATEO_READONLY';

You should see exactly one row for SLATEO_READONLY. If you get 0 rows, do not continue to the public-key step yet.

3. Generate the key pair locally

Do not generate the private key inside your repo or leave it sitting in ~/Downloads.

For a one-time setup, the safest default is:

  • generate it in a temporary directory
  • attach the public key in Snowflake
  • copy the private key into your clipboard only when you are ready to paste it into Slateo
  • then delete the local files

If you need to keep a copy, move it into your secret manager or a locked-down location with chmod 600.

KEY_TMP_DIR=$(mktemp -d)
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out "$KEY_TMP_DIR/rsa_key.p8" -nocrypt
openssl rsa -in "$KEY_TMP_DIR/rsa_key.p8" -pubout -out "$KEY_TMP_DIR/rsa_key.pub"
chmod 600 "$KEY_TMP_DIR/rsa_key.p8"
PUBK=$(grep -v "PUBLIC KEY" "$KEY_TMP_DIR/rsa_key.pub" | tr -d '\n')

4. Attach the public key

Build the complete ALTER USER statement with $PUBK already inlined and copy it to your clipboard:

printf "USE ROLE USERADMIN;\nALTER USER SLATEO_READONLY SET RSA_PUBLIC_KEY = '%s';\n" "$PUBK" | pbcopy

Then open a Snowsight worksheet, paste, and run it. Confirm the ALTER USER succeeds before continuing.

If you have the Snowflake CLI installed, you can skip the clipboard and apply it in one shot instead:

snow sql -q "USE ROLE USERADMIN; ALTER USER SLATEO_READONLY SET RSA_PUBLIC_KEY='$PUBK';"

5. Copy the private key into your clipboard

Right before you open the Slateo form, copy the private key:

pbcopy < "$KEY_TMP_DIR/rsa_key.p8"

Then open the Snowflake connection form in Slateo:

  1. Go to AdminData Sources
  2. Click Add Data Source
  3. Select Snowflake
  4. Set Authentication Method to Private Key

Then paste the clipboard contents into the Private Key field in that form.

Use:

  • Name: any friendly label, for example Production Snowflake
  • Account: your Snowflake account identifier, for example xy12345.us-east-1
  • User: SLATEO_READONLY
  • Auth method: Private Key
  • Private Key: paste the clipboard contents
  • Warehouse: your Snowflake warehouse name, for example SLATEO_WH
  • Database: your default database, for example ANALYTICS
  • Schema: your default schema, for example PUBLIC
  • Role: SLATEO_READONLY_ROLE

6. Back in Slateo

Now click Test Connection. After that, continue with the warehouse/database/schema grants below if you have not already applied them.

7. Clean up the local key files after import

If you only needed the key for initial setup and have already pasted it into Slateo, delete the temporary files:

rm -f "$KEY_TMP_DIR/rsa_key.p8" "$KEY_TMP_DIR/rsa_key.pub"
rmdir "$KEY_TMP_DIR"

If you need to keep the private key outside Slateo, move it into a secure location first instead of leaving it in a random working directory.

Optional: repeatable local path for admins

If you expect to re-import or rotate this credential later, a stable path is reasonable. Prefer a Slateo-specific location such as:

mkdir -p ~/.config/slateo/snowflake
mv "$KEY_TMP_DIR/rsa_key.p8" ~/.config/slateo/snowflake/SLATEO_READONLY.p8
chmod 600 ~/.config/slateo/snowflake/SLATEO_READONLY.p8

If you keep the key there, treat it as the canonical local copy for this Snowflake service user until you intentionally rotate it.

Avoid storing this key in ~/.ssh unless you intentionally want Snowflake credentials mixed with SSH credentials. A Snowflake-specific path is clearer and reduces accidental misuse.


Detailed reference

The quick start above is the fastest path. The sections below explain the same setup in more detail and cover alternate choices like password fallback, USERTABLES write access, and warehouse/network configuration.

Role and service user

Create a dedicated role and service user for Slateo. Snowflake now distinguishes between human users and service users, and direct Slateo connections should use a dedicated non-human identity.

Connect to your Snowflake account using the Snowflake web console or a SQL client, then run:

-- Switch to the appropriate role
USE ROLE SECURITYADMIN;

-- Create a dedicated role for Slateo
CREATE ROLE IF NOT EXISTS SLATEO_READONLY_ROLE
  COMMENT = 'Read-only role for Slateo data analytics';

-- Switch to the user administration role
USE ROLE USERADMIN;

-- Create a dedicated service user for Slateo
CREATE USER IF NOT EXISTS SLATEO_READONLY
  TYPE = SERVICE
  DEFAULT_ROLE = SLATEO_READONLY_ROLE
  DEFAULT_WAREHOUSE = '<your_warehouse>'
  COMMENT = 'Slateo service user';

-- Switch back to security administration to grant the role
USE ROLE SECURITYADMIN;

-- Grant the role to the user
GRANT ROLE SLATEO_READONLY_ROLE TO USER SLATEO_READONLY;

Verify the user exists before moving on:

USE ROLE USERADMIN;
SHOW USERS LIKE 'SLATEO_READONLY';

Replace:

  • <your_warehouse>: The warehouse name for query execution (created in Step 3)

Snowflake user management documentation →

Authentication methods

Slateo direct Snowflake connections currently support:

  • Key-pair auth (recommended)
  • Username/password (fallback)

Snowflake also supports workload identity federation for service users, but Slateo does not currently support direct Snowflake WIF configuration.

Option A: Configure key-pair auth (recommended)

Generate an RSA key pair locally:

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

Then register the public key on the Snowflake service user:

USE ROLE USERADMIN;
ALTER USER SLATEO_READONLY SET RSA_PUBLIC_KEY = '<public_key_content>';

In Slateo, choose Private Key auth and paste the contents of rsa_key.p8.

Option B: Configure password auth (fallback)

If you need to use password auth for now, set a strong password on the service user:

USE ROLE SECURITYADMIN;
ALTER USER SLATEO_READONLY SET PASSWORD = '<secure-password>';

Then choose Username & Password in Slateo.

Snowflake key-pair authentication documentation →

Database and schema access

Grant the role read-only access to your databases and schemas.

-- Switch to the appropriate role
USE ROLE SYSADMIN;

-- Grant usage on the database
GRANT USAGE ON DATABASE <your_database> TO ROLE SLATEO_READONLY_ROLE;

-- Grant usage on the schema
GRANT USAGE ON SCHEMA <your_database>.<your_schema> TO ROLE SLATEO_READONLY_ROLE;

-- Grant SELECT on all existing tables and views in the schema
GRANT SELECT ON ALL TABLES IN SCHEMA <your_database>.<your_schema> TO ROLE SLATEO_READONLY_ROLE;
GRANT SELECT ON ALL VIEWS IN SCHEMA <your_database>.<your_schema> TO ROLE SLATEO_READONLY_ROLE;

-- Grant SELECT on all future tables and views in the schema
GRANT SELECT ON FUTURE TABLES IN SCHEMA <your_database>.<your_schema> TO ROLE SLATEO_READONLY_ROLE;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA <your_database>.<your_schema> TO ROLE SLATEO_READONLY_ROLE;

-- Verify the grants
SHOW GRANTS TO ROLE SLATEO_READONLY_ROLE;

Replace:

  • <your_database>: Your database name
  • <your_schema>: Your schema name (typically PUBLIC unless you use custom schemas)

Snowflake access control documentation →

Multiple databases or schemas:

If you have multiple databases or schemas, repeat the grants for each one:

-- Example: Grant access to multiple schemas
GRANT USAGE ON DATABASE ANALYTICS TO ROLE SLATEO_READONLY_ROLE;
GRANT USAGE ON SCHEMA ANALYTICS.PRODUCTION TO ROLE SLATEO_READONLY_ROLE;
GRANT USAGE ON SCHEMA ANALYTICS.STAGING TO ROLE SLATEO_READONLY_ROLE;

GRANT SELECT ON ALL TABLES IN SCHEMA ANALYTICS.PRODUCTION TO ROLE SLATEO_READONLY_ROLE;
GRANT SELECT ON FUTURE TABLES IN SCHEMA ANALYTICS.PRODUCTION TO ROLE SLATEO_READONLY_ROLE;

GRANT SELECT ON ALL TABLES IN SCHEMA ANALYTICS.STAGING TO ROLE SLATEO_READONLY_ROLE;
GRANT SELECT ON FUTURE TABLES IN SCHEMA ANALYTICS.STAGING TO ROLE SLATEO_READONLY_ROLE;

Optional: enable file uploads (USERTABLES write access)

If you want Slateo users to upload CSVs and create tables from them, create a dedicated schema named USERTABLES and grant write access to the Slateo role.

-- Create the USERTABLES schema in the database used by your Slateo connection
CREATE SCHEMA IF NOT EXISTS <your_database>.USERTABLES;

-- Grant required privileges to the Slateo role
GRANT USAGE ON SCHEMA <your_database>.USERTABLES TO ROLE SLATEO_READONLY_ROLE;
GRANT CREATE TABLE ON SCHEMA <your_database>.USERTABLES TO ROLE SLATEO_READONLY_ROLE;

Warehouse access

Grant the role access to a warehouse for query execution. You can use an existing warehouse or create a dedicated one for Slateo.

Option A: Use an existing warehouse

-- Grant usage on an existing warehouse
GRANT USAGE ON WAREHOUSE <your_warehouse> TO ROLE SLATEO_READONLY_ROLE;

Option B: Create a dedicated warehouse (recommended)

Creating a dedicated warehouse provides better cost tracking and resource isolation:

-- Switch to the appropriate role
USE ROLE SYSADMIN;

-- Create a dedicated warehouse for Slateo
CREATE WAREHOUSE IF NOT EXISTS SLATEO_WH
  WAREHOUSE_SIZE = 'X-SMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE
  COMMENT = 'Dedicated warehouse for Slateo queries';

-- Grant usage to the Slateo role
GRANT USAGE ON WAREHOUSE SLATEO_WH TO ROLE SLATEO_READONLY_ROLE;

Snowflake warehouse documentation →

Warehouse configuration best practices:

  • Size: Start with X-SMALL for most workloads
  • Auto-suspend: Set to 60-300 seconds to balance cost and query latency
  • Auto-resume: Enable to automatically start the warehouse when queries are submitted
  • Multi-cluster: Not needed for Slateo (single-cluster is sufficient)

Optional: network access

If your Snowflake account uses network policies to restrict access, you may need to allowlist Slateo's IP addresses.

Contact your Slateo account manager for the current list of IP addresses to allowlist.

To add a network policy:

-- Switch to the appropriate role
USE ROLE SECURITYADMIN;

-- Create or alter a network policy
CREATE NETWORK POLICY IF NOT EXISTS SLATEO_NETWORK_POLICY
  ALLOWED_IP_LIST = ('1.2.3.4', '5.6.7.8')
  COMMENT = 'Network policy for Slateo access';

-- Apply the network policy to the user
ALTER USER SLATEO_READONLY SET NETWORK_POLICY = SLATEO_NETWORK_POLICY;

Snowflake network policies documentation →

Configure the connection in Slateo

Add your Snowflake connection in the Slateo admin panel.

  1. Log in to your Slateo workspace
  2. Navigate to AdminData SourcesAdd Data Source
  3. Select Snowflake
  4. Enter the connection details:
    • Name: A friendly name for this connection (e.g., Production Analytics)
    • Account: Your Snowflake account identifier (format: xy12345.us-east-1 or xy12345.us-east-1.aws)
    • User: SLATEO_READONLY
    • Authentication Method: Private Key (recommended) or Username & Password
    • Password / Private Key: The credential you configured in Step 1a
    • Warehouse: The warehouse name (e.g., SLATEO_WH or your existing warehouse)
    • Database: Your default database name (optional, can be changed later)
    • Schema: Your default schema name (optional, can be changed later)
    • Role: SLATEO_READONLY_ROLE
  5. Click Test Connection to verify connectivity
  6. Click Save to complete the setup

Finding your Snowflake account identifier →


Next steps

After you complete the setup:

  1. Schema discovery: Slateo automatically scans your accessible databases and schemas to discover available tables and views (typically within 5 minutes)
  2. Verify access: Check that all expected databases, schemas, and tables appear in your Slateo workspace
  3. Monitor warehouse usage: Review warehouse usage in the Snowflake web console to track costs
  4. Start querying: Navigate to your workspace to start analyzing your Snowflake data

Security considerations

Credential management

  • Prefer key-pair auth: Use key-pair auth for direct Slateo connections whenever possible
  • If using passwords, treat them as fallback: Use strong passwords and rotate them regularly
  • Store credentials securely: Use a secure secret manager or password vault
  • Use a service user: Keep human logins and automated Slateo access separate

To rotate the password:

USE ROLE SECURITYADMIN;
ALTER USER SLATEO_READONLY SET PASSWORD = '<new-secure-password>';

To rotate the public key:

USE ROLE SECURITYADMIN;
ALTER USER SLATEO_READONLY SET RSA_PUBLIC_KEY = '<new-public-key>';

Access control

  • Principle of least privilege: Only grant access to databases and schemas that Slateo needs
  • Use role-based access: Keep permissions on the role, not the user
  • Review grants regularly: Audit role permissions quarterly
  • Enable query logging: Monitor query activity for unusual patterns

To review current grants:

SHOW GRANTS TO ROLE SLATEO_READONLY_ROLE;
SHOW GRANTS TO USER SLATEO_READONLY;

Monitoring and auditing

Enable query history and access logs to monitor Slateo activity:

-- View queries executed by the Slateo user
SELECT
  query_text,
  start_time,
  end_time,
  total_elapsed_time,
  warehouse_name,
  execution_status
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE user_name = 'SLATEO_READONLY'
ORDER BY start_time DESC
LIMIT 100;

Snowflake query history documentation →

Cost management

Monitor warehouse usage and costs:

  • Set resource monitors: Create resource monitors to alert on high usage
  • Review warehouse size: Scale down if queries complete quickly
  • Adjust auto-suspend: Balance cost and query latency based on usage patterns
  • Use query tags: Tag Slateo queries for easier cost attribution

To create a resource monitor:

USE ROLE ACCOUNTADMIN;

CREATE RESOURCE MONITOR SLATEO_MONITOR
  WITH CREDIT_QUOTA = 100
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO SUSPEND
    ON 100 PERCENT DO SUSPEND_IMMEDIATE;

ALTER WAREHOUSE SLATEO_WH SET RESOURCE_MONITOR = SLATEO_MONITOR;

Snowflake resource monitors documentation →


Troubleshooting

Authentication errors

If Slateo reports authentication failures:

  1. Verify the user exists and is not locked:
    USE ROLE SECURITYADMIN;
    SHOW USERS LIKE 'SLATEO_READONLY';
    
  2. Test the credentials locally:
    snowsql -a <account> -u SLATEO_READONLY -d <database> -s <schema> -w <warehouse>
    
  3. Check if the user has the correct default role:
    DESC USER SLATEO_READONLY;
    
  4. Verify the password hasn't expired (if password policies are enabled)

Permission errors

If Slateo can connect but cannot query certain tables or views:

  1. Verify the role has the correct grants:
    SHOW GRANTS TO ROLE SLATEO_READONLY_ROLE;
    
  2. Check if the role has access to the specific schema:
    SHOW GRANTS ON SCHEMA <database>.<schema>;
    
  3. Verify future grants are configured:
    SHOW FUTURE GRANTS IN SCHEMA <database>.<schema>;
    
  4. Test access by switching to the Slateo role:
    USE ROLE SLATEO_READONLY_ROLE;
    USE WAREHOUSE <warehouse>;
    SELECT * FROM <database>.<schema>.<table> LIMIT 10;
    

Warehouse errors

If queries fail with warehouse errors:

  1. Verify the warehouse exists and is accessible:
    SHOW WAREHOUSES LIKE '<warehouse>';
    SHOW GRANTS ON WAREHOUSE <warehouse>;
    
  2. Check if the warehouse is suspended:
    ALTER WAREHOUSE <warehouse> RESUME;
    
  3. Verify the role has USAGE privilege on the warehouse:
    GRANT USAGE ON WAREHOUSE <warehouse> TO ROLE SLATEO_READONLY_ROLE;
    

Network policy errors

If connection fails due to network policies:

  1. Check which network policy is applied:
    DESC USER SLATEO_READONLY;
    
  2. Review the network policy allowed IPs:
    DESC NETWORK POLICY <policy_name>;
    
  3. Verify Slateo's IP addresses are in the allowed list
  4. Contact your Slateo account manager for the current IP addresses

Schema not appearing in Slateo

If a schema doesn't appear in Slateo after granting access:

  1. Verify the schema exists and contains tables:
    SHOW TABLES IN SCHEMA <database>.<schema>;
    
  2. Check that the role has USAGE on both database and schema:
    SHOW GRANTS TO ROLE SLATEO_READONLY_ROLE;
    
  3. Trigger a manual schema refresh in Slateo:
    • Go to AdminData Sources
    • Find your Snowflake connection
    • Click Refresh Schema

Advanced configuration

Other authentication and connectivity options

  • Workload identity federation (WIF): Snowflake supports WIF for TYPE=SERVICE users, but Slateo direct Snowflake connections do not yet support configuring it. If your organization requires WIF, use key-pair auth for now.

  • OAuth: Snowflake supports OAuth, but Slateo direct/server Snowflake does not use it. Snowflake OAuth is relevant to Slateo desktop/local execution instead.

  • PrivateLink / private connectivity: Snowflake supports private connectivity patterns such as PrivateLink. Use this only if your organization requires private network paths.

  • Snowflake key-pair authentication documentation

  • Snowflake OAuth documentation

  • Snowflake PrivateLink documentation


Additional resources

For additional support or questions, contact your Slateo account manager.

Was this page helpful?

Was this page helpful?