This page details how to use the /data
v1 API to connect a Snowflake host to Immuta using key pair authentication. This connection works with a single set of credentials rather than configuring an integration and registering data sources separately. To manage your host, see the Manage a host reference guide.
To complete this guide, you must be a user with the following:
Immuta permissions:
APPLICATION_ADMIN
CREATE_DATA_SOURCE
Snowflake permissions:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION
APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION
Complete the following steps to connect a Snowflake host:
Use the /integrations/scripts/create
endpoint to receive a script.
Run the script in Snowflake.
Use the /data/connection
endpoint to finish creating the connection to your host and Immuta.
POST
/integrations/scripts/create
Copy the request and update the <placeholder_values>
with your connection details. Then submit the request.
Find descriptions of the editable attributes in the table below and of the full payload in the Integration configuration payload reference guide. All values should be included and those you should not edit are noted.
Step one will return a script. Copy the script and run it in your Snowflake environment as a user with the permissions listed in the requirements section.
The script will allow an Immuta system user to authenticate using the username and private key you specified in step one. This system user will have the permissions listed on the Snowflake integration reference guide. Additionally, the script will create the database you specified in step one.
POST
/data/connection
Copy the request and update the <placeholder_values>
with your connection details. Note that the connection details here should match the ones used in step one. Then submit the request.
Find descriptions of the editable attributes in the table below and of the full payload in the Snowflake object table. All values should be included and those you should not edit are noted.
Test run
Opt to test and validate the create connection payload using a dry run:
POST
/data/connection/test
Attribute | Description | Required |
---|---|---|
Attribute | Description | Required |
---|---|---|
Attribute | Description |
---|---|
config.username string
The username of the system account that can act on Snowflake objects and configure the host.
Yes
config.privateKey string
The private key. Replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
Yes
config.host string
The URL of your Snowflake account.
Yes
config.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
config.database string
Name of a new empty database that the Immuta system user will manage and store metadata in.
Yes
connectionKey string
A unique name for the host connection.
Yes
connection object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
connection.hostname string
The URL of your Snowflake account. This is the same as host
.
Yes
connection.port integer
The port to use when connecting to your Snowflake account host. Defaults to 443
.
Yes
connection.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
connection.role string
The privileged Snowflake role used by the Immuta system account when configuring the Snowflake host. At minimum, it must be able to see the data that Immuta will govern.
Yes
connection.username string
The username of the system account that can act on Snowflake objects and configure the host.
Yes
connection.privateKeyPassword string
The Snowflake private key password. Required if the private key is encrypted.
No
connection.privateKey.userFilename string
The name of your private key file on your machine.
Yes
connection.privateKey.content string
The private key. Replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added. This is the same as config.privateKey
.
Yes
nativeIntegration object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
nativeIntegration.config.username string
Same as connection.username
Yes
nativeIntegration.config.privateKeyPassword string
Same as connection.privateKeyPassword
No
nativeIntegration.config.privateKey.keyName string
Same as connection.keyName
Yes
nativeIntegration.config.privateKey.userFilename string
Same as connection.userFilename
Yes
nativeIntegration.config.privateKey.content string
Same as connection.content
Yes
nativeIntegration.config.host string
Same as connection.hostname
Yes
nativeIntegration.config.port integer
Same as connection.port
Yes
nativeIntegration.config.warehouse string
Same as connection.warehouse
Yes
nativeIntegration.config.database string
Name of a new empty database that the Immuta system user will manage and store metadata in.
Yes
objectPath string
The list of names that uniquely identify the path to a data object in the remote platform's hierarchy. The first element should be the associated connectionKey
.
bulkId string
A bulk ID that can be used to search for the status of background jobs triggered by this request.