Required Snowflake Objects

Regardless of how your ALTR account is created, ALTR requires five Snowflake objects: a database, a stored procedure, a service user, a role, and a warehouse. If you create your account through Snowflake Marketplace, these objects are created for you. On the default manual path, you create the user and database yourself, and the stored procedure creates the role and warehouse.

Danger

Do not change the SETUP_ALTR_SERVICE_ACCOUNT stored procedure. If you need to use a service user different from the default (PC_ALTR_USER for Snowflake Marketplace, ALTR_SERVICE_USER for the default manual setup), follow the custom service user instructions on Create a Service User so that ALTR continues to work correctly.

Object	Marketplace Object Name	Default Manual Object Name
Database	PC_ALTR_DB	PC_ALTR_DB
Stored Procedure	SETUP_ALTR_SERVICE_ACCOUNT (placed in PC_ALTR_DB automatically)	SETUP_ALTR_SERVICE_ACCOUNT (placed in the database you create to house it)
User	PC_ALTR_USER	ALTR_SERVICE_USER
Role	PC_ALTR_ROLE	ALTR_SERVICE_ROLE
Warehouse	PC_ALTR_WH	ALTR_SERVICE_WH

These are the default, recommended object names — not required. Use the custom-object-name version of the setup stored procedure if you use different names — see Create a Service User.

Run the SETUP_ALTR_SERVICE_ACCOUNT stored procedure so the ALTR service user has the privileges it needs. See Create a Service User for the steps and when to re-run it, and Service User Privilege Requirements for the privileges it grants.

Note

ALTR recommends assigning a network policy to the service user to further restrict access. See Whitelisting ALTR’s IP Addresses.

Snowflake Privilege Grants to Future Tables

The stored procedure grants privileges to your ALTR service role on current and future database, schema, and table objects.

Snowflake allows future grants at both the database level and the schema level; when a privilege is granted to a future object of the same type at both levels, the schema-level grant takes precedence and the database-level grant is ignored. ALTR sets its future-object privileges at the database level rather than the schema level, so the setup procedure doesn’t need to run again when new schemas or tables are added to an already-connected database. For example, the stored procedure uses:

GRANT SELECT ON FUTURE TABLES IN DATABASE "<DATABASE>";

instead of:

GRANT SELECT ON FUTURE TABLES IN SCHEMA "<SCHEMA>";

If your database operations require schema-level privileges granted to other roles on future tables in an ALTR-connected database, explicitly grant SELECT on future tables in that schema to the ALTR service role as well.

Service User Authentication

Key-pair authentication is the standard authentication method for the ALTR service user. Password authentication is supported only for service users created before ALTR’s move to key-pair authentication, and ALTR recommends migrating those service users to key-pair authentication.

If you change credentials for your service user in Snowflake without also updating them in ALTR, ALTR will be unable to connect to Snowflake — existing masking and access control policies continue to function, but ALTR can’t define new policies or generate accurate query audit logs. If you need to use a different service user or role name to match your naming convention, follow the custom service user steps on Create a Service User.