Configure ALTR's Snowflake Service User

ALTR uses a "Service User" to connect to Snowflake, which is an account to your Snowflake instance used to create and enforce governance policies. This page guides you though how to manage this Service User and ensure it has all of the necessary permissions for policy creation and enforcement.

What is the Snowflake Service User?

In order to create and enforce data governance policies, ALTR needs to be able to access your Snowflake account and create schema objects. It does this just like any other Snowflake user - by having a User, Role, and warehouse with which to communicate with Snowflake. We refer to these as the “Service User”, “Service Role”, and “Service Warehouse”.

When signing up for ALTR through Snowflake Partner Connect, Snowflake automatically creates a user, role, and warehouse for ALTR - PC_ALTR_USER, PC_ALTR_ROLE, and PC_ALTR_WAREHOUSE. Although Snowflake automatically grants some permissions to PC_ALTR_ROLE, these are not sufficient to create and enforce governance policies. This document describes what permissions are required by ALTR’s Service User, why it needs them, and how you can permission (and re-permission) PC_ALTR_ROLE.

If you created your ALTR account directly through ALTR’s website, Snowflake did not auto-create a service user, role, and warehouse. Instead, you likely executed ALTR’s stored procedure for creating a service user - or you made your own. If you went through the stored procedure and need to re-permission the Service User (ALTR_SERVICE_USER), you can follow the same instructions as below - though be sure to set the parameter to FALSE instead of TRUE and ensure it’s affecting the correct role.

What is the Stored Procedure?

To quickly and easily configure ALTR’s Service User with all of the permissions required to create and enforce governance rules, we have prepared a Stored Procedure that enables you to automate grants with just a few SQL commands. If you signed up through Snowflake Partner Connect, ALTR automatically created a copy of this stored procedure in PC_ALTR_DB. If you signed up through ALTR’s website, you likely copied and pasted the stored procedure yourself.

Running the Stored Procedure iterates through every database in your Snowflake Account and grants ALTR’s service user particular permissions to create and enforce governance policies. If you’ve created new Snowflake databases since starting with ALTR, or if you have some other permissions issue, re-running the stored procedure will re-configure the Service User to the correct permissions. The stored procedure must be run as ACCOUNTADMIN. Sometimes, ALTR updates the service user to account for new features enabled by Snowflake, such as the ability to create and maintain Row Access Policies. If you are having Service User issues and have not run the stored procedure in awhile, copy the latest version from this page instead of relying on any older version.

What Permissions does ALTR ask for, and why?

The stored procedure grants PC_ALTR_ROLE (Snowflake Partner Connect Signups) or ALTR_SERVICE_USER (altr.com Signups) the following permissions:

‍

CREATE DATABASE: This is used for debugging

APPLY MASKING POLICY: ALTR Uses Snowflake’s Dynamic Data Masking Policies to create and enforce Column Access Policies. When a column is connected to ALTR, ALTR creates a Masking Policy for that column in Snowflake. Once that policy is created, ALTR is invoked by Snowflake to make a governance decision each time that column is queried.

CREATE INTEGRATION: ALTR communicates with Snowflake to make governance decisions through an API integration. This permission enables ALTR’s Service User to create those API integrations for each connected database.

APPLY TAG: ALTR can invoke Snowflake’s Classification tool to generate SEMANTIC_CATEGORY and PRIVACY_CATEGORY tags, which can then be leveraged when defining Tag-Based Column Access Policies. The APPLY TAG permission is required to assign these tags to columns during a Snowflake Classification.

APPLY ROW ACCESS POLICY: This permission is required for ALTR to apply Row Access Policies to tables in Snowflake.

MONITOR ON WAREHOUSE: ALTR monitors warehouse activity to identify when sensitive columns are access by users. This is particularly used for ALTR’s Thresholding and Rate Limiting capabilities, as monitoring warehouse activity enables ALTR to identify exactly how many values of a column were accessed.

USAGE ON DATABASE: This enables ALTR to access databases in Snowflake to create the necessary objects to enforce governance policies

CREATE SCHEMA ON DATABASE: ALTR creates all it’s governance objects in a custom ALTR_DSAAS schema, ensuring that these policies are separated from data-holding schemas.

USAGE ON SCHEMA: This enables ALTR to create necessary schema-level objects to create and enforce governance policies.

SELECT ON TABLES: ALTR does not automatically select or store any raw data (actual values) from client Snowflake Accounts. However, if you opt-in to a Google DLP classification, ALTR uses this permission to randomly sample data from tables for classification. ALTR does not persist these samples.

CREATE TAG ON SCHEMA: ALTR can invoke Snowflake’s Classification tool to generate SEMANTIC_CATEGORY and PRIVACY_CATEGORY tags, which can then be leveraged when defining Tag-Based Column Access Policies. The CREATE TAG permission is required to create these tags during a Snowflake Classification.

CREATE ROW ACCESS POLICY: This permission is required for ALTR to create Row Access Policies in Snowflake.

GRANT IMPORTED PRIVILEGES: If you opt to allow ALTR to access your database’s query history to generate Data Usage Analytics for all queries, ALTR requires this permission to access Snowflake’s Access History Views.

How to configure the Snowflake Service User

When signing up for ALTR though Snowflake Partner Connect, ALTR automatically loads a stored procedure into PC_ALTR_DB that can be used to configure PC_ALTR_ROLE. During the onboarding process, you have the option to:

1. Grant ACCOUNTADMIN to PC_ALTR_USER, which PC_ALTR_USER uses to automatically configure PC_ALTR_ROLE
2. Manually run the stored procedure to configure PC_ALTR_ROLE

Note: ALTR uses ACCOUNTADMIN only to run the stored procedure and configure PC_ALTR_ROLE. Any further actions taken by ALTR’s service user are done using PC_ALTR_ROLE unless you specify otherwise.

After onboarding, there are many reasons why you may need to re-permission your Service User. These include:

1. ALTR updates the required Service User permissions to enable a new feature (ex: Row Access Policies)
2. You have created new databases that you want to connect to ALTR
3. Your Service User’s permissions were altered and no longer contain needed grants

In order to re-permission your service user, run the two scripts below as ACCOUNTADMIN in Snowflake. If your ALTR account was created via altr.com instead of Snowflake Partner Connect, run the second command as FALSE instead of TRUE so that it affects ALTR_SERVICE_ROLE instead of PC_ALTR_ROLE. Note: if you have many databases in your Snowflake account, this script may significant time to run.

Troubleshooting and FAQs

1. I have a “permissions requested” warning on a database - how do I fix it?
   To fix a “permissions requested” warning for a database, re-run the latest stored procedure using the instructions above
   ‍
2. I changed the password for my Service User - what do I do?
   If you connected the database through the Snowflake Partner Connect Onboarding or through the Snowflake Partner Connect option on Altr’s Data Sources page, reach out to support@altr.com to update your Service User Password.
   If you connected the database manually specifying the service user, you can update the password associated with the service user through the “advanced settings” section for the database on the Data Sources Page
   ‍
3. What permissions does ALTR require to communicate with Snowflake?
   See the list in this document
   ‍
4. I’m unable to connect one of my Snowflake Databases to ALTR.
   Due to limitations on External Functions, ALTR only supports connecting non-shared databases.
   If your database isn’t from a Share and you’re having trouble connecting, it’s likely that your Service User doesn’t have the necessary permissions to access that database. You can update the Service User using the instructions above.
   ‍
5. I only want ALTR to be able to access a limited number of databases, but the stored procedure grants access to all of them.
   Reach out to support@altr.com and we will work with you to grant permissions only to the databases you want to connect to ALTR.
   ‍
6. I don’t want to grant permissions to ALTR for features I don’t intend to use.
   Reach out to support@altr.com and we will work with you to grant permissions only for the ALTR features you intend to use.

‍