Getting Started with ALTR & Snowflake
Configure ALTR's Snowflake Service User
Connect Snowflake Databases
Connect Columns to ALTR
Creating Policy & Manage Data
Classification
Analytics
Column Access Policies
Views
Thresholds
Row Access Policy
Audit Logs
Settings
Tokenization
Tag-Based Data Masking
Tokenization API
Management API
ALTR Driver JDBC Installation
ALTR Driver ODBC Installation
Configure Tableau to Gain User Level Observability
Integrating ALTR Notifications with AWS S3
TDS Proxy Installation
CDM Installation
Custom Masking and Extensibility Functions
Bring Your Own Key for Tokenization
Open-Source Integrations
ALTR uses an account (which is 'Service User') to connect 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.
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, then 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 Partner Connect and need to re-permission the Service User (ALTR_SERVICE_USER), then you can follow the same instructions as below; however, set the parameter to FALSE instead of TRUE and make sure it's affecting the correct role.
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, then ALTR automatically created a copy of this stored procedure in PC_ALTR_DB.
If you signed up through ALTR’s website, then 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, then 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, then copy the latest version from this page instead of relying on any older version.
The stored procedure grants PC_ALTR_ROLE (Snowflake Partner Connect Signups) or ALTR_SERVICE_USER
(altr.com Signups) the following permissions:
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:
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. Some of them are listed below.
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, then run the second command as FALSE instead of TRUE so that it affects ALTR_SERVICE_ROLE instead of PC_ALTR_ROLE.
Notes:
This section explains ALTR's capability to tag Snowflake warehouse and databases that it governs and the reason why it's done.
Snowflake object tags are metadata that can be set on any Snowflake object such as a database, column, table, warehouse, user, or role. Object tags are key-value pairs which Snowflake calls the “Tag Name” and “Tag Value”. For more details, review Snowflake’s Object Tagging documentation.
The reason why ALTR tags objects with a custom 'ALTR_GOVERNED' tag is to make it easier for you to identify which of your connected Snowflake databases and monitored warehouses are (and are not) governed by our system. This added value that we provide will give you greater clarity to help with your data governance strategy.
ALTR creates a custom Snowflake Object Tag, 'ALTR_GOVERNED' and assigns that tag to any database connected to ALTR and any warehouse monitored by ALTR’s service user. This process occurs when a database is first connected and during ALTR’s database connection check, which repeats every 24 hours.
During the connection check, ALTR checks for the presence of the PC_ALTR_DB database. If that database doesn't exist, then no action is taken. However, if it does exist, then ALTR checks for the presence of the 'ALTR_GOVERNED' tag in the database and creates it if it doesn't already exist. Next, ALTR tags the connected database with the "ALTR_GOVERNED"="TRUE" if it's not already tagged. ALTR also checks every database that the service user has access to and similarly tags it "ALTR_GOVERNED"="TRUE" if it is not already tagged.
If PC_ALTR_DB does not exist for a client, then databases and warehouses will not be tagged. Manually creating PC_ALTR_DB will enable ALTR to tag databases and warehouses during the next connection check. Removing PC_ALTR_DB will remove the ALTR_GOVERNED tag from Snowflake, automatically de-tagging any databases and warehouses.
If the ALTR_GOVERNED tag is manually removed but PC_ALTR_DB still exists, then ALTR_GOVERNED will be automatically recreated and tagged during the next connection check.
NOTE: Removing PC_ALTR_DB on a Snowflake account still connected to ALTR may cause instability or governance issues. You should not remove PC_ALTR_DB if you intend to continue using ALTR.
ALTR already has the capability to ingest information about column-level Snowflake object tags and use those tags for the purpose of setting governance policies at scale. This integration is wholly unrelated; it sets tags on Snowflake databases and warehouses instead of reading them.
ALTR’s existing integration with Snowflake object tags only considers column-level tags and will not import the “ALTR_GOVERNED” tag unless (for some reason) you were to manually assign that tag to a column in Snowflake.
When disconnecting a Snowflake database from ALTR, what happens next is ALTR will untag the ALTR_GOVERNED tag from the database. ALTR does not automatically unset the ALTR_GOVERNED tag on warehouses because there could be other connected databases whose warehouse activity is monitored.
If you wish to stop using ALTR altogether and no longer want the ALTR_GOVERNED tag on your warehouses, then you can manually drop the tag from PC_ALTR_DB after you disconnect all Snowflake databases from ALTR. This will automatically unset the tag from any warehouses.
NOTE: If you manually drop the ALTR_GOVERNED tag but still have databases connected to ALTR, then the ALTR_GOVERNED tag will be recreated during the next database connection check.
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.
I changed the password for my Service User. What do I do now?
If you connected the database through the Snowflake Partner Connect Onboarding or through the Snowflake Partner Connect option on the 'Data Sources' page in ALTR, then reach out to support@altr.com to update your Service User Password.
If you connected the database by manually specifying the service user, then you can update the password associated with the service user through the 'Advanced Settings' section for the database on the Data Sources page.
What permissions does ALTR require to communicate with Snowflake?
See the list in this document.
I’m unable to connect one of my Snowflake Databases to ALTR. Why?
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, then 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.
Why is ALTR tagging Snowflake databases and warehouses?
ALTR is doing this to make it easier to attribute workflows and data governed by ALTR.
When does ALTR tag Snowflake databases and warehouses?
During the database connection check which occurs when a database is first connected to ALTR and then once every 24 hours per connected database.
Where does the “ALTR_GOVERNED” tag live in Snowflake?
The ALTR_GOVERNED tag is defined in the PC_ALTR_DB database. PC_ALTR_DB is manually created as a part of the Snowflake Partner Connect process.
What if PC_ALTR_DB does not exist in a client's Snowflake account?
If PC_ALTR_DB does not exist for a Snowflake account, then ALTR will not tag monitored warehouses and connected databases. If a user manually creates PC_ALTR_DB, then ALTR will start tagging warehouses and connected databases with the next database connection check.
Why do some clients have multiple ALTR_GOVERNED tags in their Snowflake account?
In a previous iteration of this integration, ALTR created a different “ALTR_GOVERNED” tag in each connected Snowflake database instead of relying on a single tag in PC_ALTR_DB. Because of this, any clients with databases connected to ALTR between Feb 1 and Feb 8, 2023 will still see these tags in their Snowflake account and assigned to their connected Snowflake databases. If you desire, these tags can be safely removed.
I don’t want to grant permissions to ALTR for features I don’t intend to use. What can I do?
Reach out to support@altr.com and we will work with you to grant permissions only for the ALTR features you intend to use.
I only want ALTR to be able to access a limited number of databases but the stored procedure grants access to all of them. How can I impose a limit?
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.