Configure ALTR's Snowflake Service User

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.

Snowflake Service User Description

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.

Stored Procedure Description

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.

Permissions that ALTR Asks 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: This enables ALTR to identify tables within Snowflake. ALTR does not automatically select or store any raw data (actual values) from client Snowflake Accounts. However, if you opt-in to Google DLP classification, then ALTR uses this permission to randomly sample data from tables present within a Snowflake database. 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.
• SELECT ON VIEWS: This enables ALTR to identify views in Snowflake.
• SELECT ON MATERIALIZED VIEWS: This enables ALTR to identify materialized views within Snowflake.

Configuring 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:

• Grant ACCOUNTADMIN to PC_ALTR_USER, which PC_ALTR_USER uses to automatically configure PC_ALTR_ROLE
• 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. Some of them are listed below.

• ALTR updates the required Service User permissions to enable a new feature (ex: Row Access Policies).
• You have created new databases that you want to connect to ALTR.
• 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, then run the second command as FALSE instead of TRUE so that it affects ALTR_SERVICE_ROLE instead of PC_ALTR_ROLE.

‍
Notes:

• Even if you're not using Partner Connect, we recommend that you always use PC_ALTR_USER . If you're an EXISTING CUSTOMER who uses ALTR_SERVICE_USER then you still need to run the stored procedure call as FALSE instead of TRUE.
• If you have many databases in your Snowflake account, then this script may take a significant amount of time to run.

‍

Tag Snowflake Warehouses and Databases

This section explains ALTR's capability to tag Snowflake warehouse and databases that it governs and the reason why it's done.

What are Snowflake Object Tags?

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.

Why Does ALTR Tag Snowflake Objects?

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.

How ALTR Tags Databases and Warehouses

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.

How These Tags Relate to ALTR's Snowflake Object Tag Import

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.

Untagging Snowflake Objects

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.

FAQs and Troubleshooting

Warnings and Passwords

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.

‍
Permissions that ALTR requires

What permissions does ALTR require to communicate with Snowflake?
See the list in this document.

Connectivity Issues

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.

Tags

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.

Other

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.

‍

‍