Snowflake

Trustle reads users, roles, role grants, object privileges, and sign-in, query, and access history from Snowflake. Trustle can create, disable, and drop users, and grant and revoke roles.

Prerequisites

• A Snowflake user with the ACCOUNTADMIN role. Only ACCOUNTADMIN can grant access to the SNOWFLAKE database.
• Enterprise Edition or higher, for object-level usage. On Standard Edition, Snowflake has no access history. Trustle then uses query history only, so the permission analysis is less precise.
• openssl on your computer, to create a key pair.
• An identity provider connected in Trustle, for example Okta or Microsoft Entra ID. Trustle hides SaaS Applications until one is connected.

Caution

Trustle always signs in as the user TRUSTLE_SERVICE_ACCOUNT, with the warehouse TRUSTLE_ETL_WH and the role SECURITYADMIN. You cannot change these names in Trustle. Use them exactly as the SQL below shows.

Configure Snowflake

Step 1: Open a SQL worksheet

1. Sign in to Snowsight as a user with the ACCOUNTADMIN role.
2. Go to Projects → Workspaces.
3. Create a new SQL file. You run the SQL from the next steps in this file.

Step 2: Grant permissions to a Trustle role

1. Run this SQL. It creates a role for Trustle and grants it the access in the table below.

   CREATE ROLE IF NOT EXISTS TRUSTLE_ROLE COMMENT = 'Role for Trustle integration - DO NOT DELETE.';
   
   GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE TRUSTLE_ROLE;
   
   GRANT ROLE SECURITYADMIN TO ROLE TRUSTLE_ROLE;

   Permission	Required	What Trustle does with it
   SECURITYADMIN role	Yes	Reads users, roles, and grants. Creates and disables users. Grants and revokes roles.
   IMPORTED PRIVILEGES on the SNOWFLAKE database	Yes	Reads sign-in history, query history, access history, and grants from ACCOUNT_USAGE.
   OWNERSHIP on a user	Optional	Drops that user. SECURITYADMIN can drop the users that it or USERADMIN owns. Without ownership, Trustle cannot drop the user.

Step 3: Create the warehouse

1. Run this SQL. Trustle runs its ACCOUNT_USAGE queries on this warehouse.

   CREATE WAREHOUSE IF NOT EXISTS TRUSTLE_ETL_WH
   WAREHOUSE_SIZE = 'XSMALL'
   AUTO_SUSPEND = 60
   AUTO_RESUME = TRUE;
   
   GRANT USAGE ON WAREHOUSE TRUSTLE_ETL_WH TO ROLE TRUSTLE_ROLE;

Step 4: Create a key pair

1. On your computer, run these commands. They create an unencrypted private key in PKCS#8 format, and its public key.

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

Caution

Trustle cannot read an encrypted private key. Keep the -nocrypt option.

Step 5: Create the service user

1. Open trustle_rsa_key.pub. Copy the key without the -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- lines.

2. Run this SQL. Replace <public-key> with the key you copied.

   CREATE USER TRUSTLE_SERVICE_ACCOUNT
   TYPE = SERVICE
   DEFAULT_ROLE = SECURITYADMIN
   DEFAULT_WAREHOUSE = TRUSTLE_ETL_WH
   DEFAULT_SECONDARY_ROLES = ('ALL')
   COMMENT = 'Service Account for Trustle integration - DO NOT DELETE.'
   RSA_PUBLIC_KEY = '<public-key>';
   
   GRANT ROLE TRUSTLE_ROLE TO USER TRUSTLE_SERVICE_ACCOUNT;
   GRANT ROLE SECURITYADMIN TO USER TRUSTLE_SERVICE_ACCOUNT;

   Trustle signs in with the role SECURITYADMIN, so the user needs it granted directly. DEFAULT_SECONDARY_ROLES keeps the TRUSTLE_ROLE grants active in the same session, so Trustle can use the warehouse and read account usage.

Step 6: Collect the values for Trustle

Trustle field	Where to find it in Snowflake	Example
Account Identifier	Snowsight → account menu → account details → Account Identifier	organization-account_name or xy12345.us-east-1
Private Key	The whole trustle_rsa_key.p8 file from Step 4	-----BEGIN PRIVATE KEY----- … -----END PRIVATE KEY-----

Connect in Trustle

1. In Trustle, go to Connections.
2. Under SaaS Applications, find Snowflake and click Connect.
3. Enter a Connection Name, for example Snowflake production. Description is optional.
4. Enter the values from Step 6. Paste the whole private key, with the BEGIN and END lines.
5. Click Test Connection.
6. After the test passes, click Save Connection.

Note

Test Connection checks that Trustle can sign in. It does not check the grants or the warehouse. Do the steps in Verify after the first sync.

Verify

1. On the Connections page, open the Snowflake connection.
2. Wait for the first sync to finish.
3. Check that the user count matches the result of SHOW USERS in Snowflake.
4. Check that the roles from SHOW ROLES show in Trustle.

If something is missing, see Troubleshooting.

Security notes

Note

• TRUSTLE_SERVICE_ACCOUNT is a SERVICE user. It cannot sign in to Snowsight with a password.
• Store the private key in a secret manager. Never commit it to a repository. Delete the local copy after you paste it into Trustle.
• To rotate the key, set the new public key in RSA_PUBLIC_KEY_2. Paste the new private key into the Trustle connection. Then remove the old public key.
• SECURITYADMIN can manage grants for the whole account. Protect the private key like an administrator password.

Troubleshooting

Test Connection fails

Trustle does not show the reason yet. Check these values:

• Account Identifier: use organization-account_name or xy12345.us-east-1. Do not add .snowflakecomputing.com or https://.
• Private Key: “Invalid private key format” means Trustle cannot read the key. Paste the whole .p8 file, from -----BEGIN PRIVATE KEY----- to -----END PRIVATE KEY-----. The key must not be encrypted.
• User name: “Invalid credentials: authentication failed” means Snowflake refused the sign-in. Check that the user is named exactly TRUSTLE_SERVICE_ACCOUNT.
• Public key: the public key on TRUSTLE_SERVICE_ACCOUNT must come from the same key pair as the private key. If you are not sure, make a new key pair. Then run ALTER USER TRUSTLE_SERVICE_ACCOUNT SET RSA_PUBLIC_KEY = '<public-key>' and paste the new private key.

Test Connection passes, but the sync fails

Test Connection does not use the warehouse or the grants. Check these items:

• The warehouse is named exactly TRUSTLE_ETL_WH, and the role has USAGE on it. See Step 3.
• The role has IMPORTED PRIVILEGES on the SNOWFLAKE database. See Step 2.
• TRUSTLE_SERVICE_ACCOUNT can use the role SECURITYADMIN. Run SHOW GRANTS TO USER TRUSTLE_SERVICE_ACCOUNT.

Object-level usage is missing

Snowflake records access history only on Enterprise Edition or higher. On Standard Edition, Trustle uses query history only.

Trustle cannot drop a user

Snowflake lets a role drop a user only if the role owns the user. Trustle uses SECURITYADMIN, which can drop the users that it or USERADMIN owns. Trustle cannot drop a user that another role owns, for example ACCOUNTADMIN. Transfer the ownership of that user to USERADMIN, then retry.

None of these fixes work

Email support@trustle.com. Include the error message, the connection name, and the Account Identifier. Never send a secret, key, or token.