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.
Best practice: Create a dedicated TYPE=SERVICE user, role, and warehouse for Slateo. This provides clear separation of concerns and makes it easier to monitor usage and costs.
Prerequisites
Before setting up the connection, ensure you have:
- An active Snowflake account
ACCOUNTADMINorSECURITYADMINrole to create users and rolesSYSADMINrole 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')
Important: Snowflake expects the RSA_PUBLIC_KEY value without the -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- lines. The PUBK=... command above formats it correctly.
Why not print the private key? Printing the private key to the terminal leaves it in shell scrollback and can make accidental disclosure easier. Copying directly from the file later is a better default for a one-time transfer into the Slateo UI.
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:
- Go to Admin → Data Sources
- Click Add Data Source
- Select Snowflake
- 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 →
Auth recommendation: For direct/server Snowflake connections, Slateo supports username/password and key-pair auth today. Key-pair auth is the recommended setup. Snowflake workload identity federation (WIF) is not yet supported by Slateo direct connections.
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.
Use password auth only as a fallback. Snowflake is moving away from password-based non-human authentication. If key-pair auth is workable in your environment, use that instead.
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 (typicallyPUBLICunless you use custom schemas)
Snowflake access control documentation →
Future grants are critical for dbt and ELT workflows.
If your ELT tool (dbt, Fivetran, Airbyte, etc.) drops and recreates tables on each run, GRANT SELECT ON ALL TABLES only covers tables that exist at the time the command runs. Each time your ELT tool recreates a table, Slateo loses access.
GRANT SELECT ON FUTURE TABLES ensures that new tables created in the schema automatically get the grant, regardless of which user creates them.
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;
Recommended isolation: Keep write access scoped only to USERTABLES. Continue granting read-only access to your source schemas as configured in Step 2.
After creating the USERTABLES schema and granting privileges, go to Settings → Database Connections, select your connection, and click Test Connection. This refreshes the upload capability check. The file upload option will appear on the Data Models page once the check passes.
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 sizing: Start with X-SMALL and scale up if needed. Snowflake charges based on warehouse size and runtime. The AUTO_SUSPEND setting automatically suspends the warehouse after 60 seconds of inactivity to minimize costs.
Warehouse configuration best practices:
- Size: Start with
X-SMALLfor 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 →
Most Snowflake accounts don't require network policies. Only configure this if your organization has specific network security requirements.
Configure the connection in Slateo
Add your Snowflake connection in the Slateo admin panel.
- Log in to your Slateo workspace
- Navigate to Admin → Data Sources → Add Data Source
- Select Snowflake
- Enter the connection details:
- Name: A friendly name for this connection (e.g.,
Production Analytics) - Account: Your Snowflake account identifier (format:
xy12345.us-east-1orxy12345.us-east-1.aws) - User:
SLATEO_READONLY - Authentication Method:
Private Key(recommended) orUsername & Password - Password / Private Key: The credential you configured in Step 1a
- Warehouse: The warehouse name (e.g.,
SLATEO_WHor 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
- Name: A friendly name for this connection (e.g.,
- Click Test Connection to verify connectivity
- Click Save to complete the setup
Finding your Snowflake account identifier →
Account identifier format: Your account identifier can be found in the Snowflake web console URL. For example, if your URL is https://xy12345.us-east-1.snowflakecomputing.com, your account identifier is xy12345.us-east-1.
Next steps
After you complete the setup:
- Schema discovery: Slateo automatically scans your accessible databases and schemas to discover available tables and views (typically within 5 minutes)
- Verify access: Check that all expected databases, schemas, and tables appear in your Slateo workspace
- Monitor warehouse usage: Review warehouse usage in the Snowflake web console to track costs
- 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:
- Verify the user exists and is not locked:
USE ROLE SECURITYADMIN; SHOW USERS LIKE 'SLATEO_READONLY'; - Test the credentials locally:
snowsql -a <account> -u SLATEO_READONLY -d <database> -s <schema> -w <warehouse> - Check if the user has the correct default role:
DESC USER SLATEO_READONLY; - Verify the password hasn't expired (if password policies are enabled)
Permission errors
If Slateo can connect but cannot query certain tables or views:
- Verify the role has the correct grants:
SHOW GRANTS TO ROLE SLATEO_READONLY_ROLE; - Check if the role has access to the specific schema:
SHOW GRANTS ON SCHEMA <database>.<schema>; - Verify future grants are configured:
SHOW FUTURE GRANTS IN SCHEMA <database>.<schema>; - 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:
- Verify the warehouse exists and is accessible:
SHOW WAREHOUSES LIKE '<warehouse>'; SHOW GRANTS ON WAREHOUSE <warehouse>; - Check if the warehouse is suspended:
ALTER WAREHOUSE <warehouse> RESUME; - 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:
- Check which network policy is applied:
DESC USER SLATEO_READONLY; - Review the network policy allowed IPs:
DESC NETWORK POLICY <policy_name>; - Verify Slateo's IP addresses are in the allowed list
- 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:
- Verify the schema exists and contains tables:
SHOW TABLES IN SCHEMA <database>.<schema>; - Check that the role has USAGE on both database and schema:
SHOW GRANTS TO ROLE SLATEO_READONLY_ROLE; - Trigger a manual schema refresh in Slateo:
- Go to Admin → Data Sources
- Find your Snowflake connection
- Click Refresh Schema
Advanced configuration
Other authentication and connectivity options
-
Workload identity federation (WIF): Snowflake supports WIF for
TYPE=SERVICEusers, 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.
Additional resources
- Snowflake access control overview
- Snowflake security best practices
- Snowflake warehouse sizing
- Snowflake cost optimization
For additional support or questions, contact your Slateo account manager.