Configure a Snowflake Integration
In the Snowflake integration, Immuta manages access to Snowflake tables by administering Snowflake row access policies and column masking policies on those tables, allowing users to query tables directly in Snowflake while dynamic policies are enforced.
Use the /integrations
endpoint to
Requirements
APPLICATION_ADMIN
Immuta permissionThe Snowflake user must have the following privileges:
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
Configure the integration
You have two options for configuring your Snowflake integration:
Automatic setup: Grant Immuta one-time use of credentials to automatically configure your Snowflake environment and the integration. When performing an automated installation, Immuta requires temporary, one-time use of credentials with the Snowflake privileges listed in the requirements section.
These privileges will be used to create and configure a new Immuta-managed database within the specified Snowflake instance. The credentials are not stored or saved by Immuta, and Immuta doesn’t retain access to them after initial setup is complete.
You can create a new account for Immuta to use that has these privileges, or you can grant temporary use of a pre-existing account. By default, the pre-existing account with appropriate privileges is ACCOUNTADMIN. If you create a new account, it can be deleted after initial setup is complete.
Manual setup: Run the Immuta script in your Snowflake environment yourself to configure your Snowflake environment and the integration. The specified role used to run the bootstrap needs to have the Snowflake privileges listed in the requirements section.
Automatic setup
Select the section below that matches your authentication method.
Copy the request example and replace the values with your own as directed to configure the integration settings. The examples provided use JSON format, but the request also accepts YAML.
See the config object description for parameter definitions, value types, and additional configuration options.
curl -X 'POST' \
'https://www.organization.immuta.com/integrations' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
-d '{
"type": "Snowflake",
"autoBootstrap": true,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"authenticationType": "userPassword",
"username": "[email protected]",
"password": "abc1234",
"role": "ACCOUNTADMIN"
}
}'
Replace the Immuta URL and API key with your own.
Change the config values to your own, where
host is the URL of your Snowflake account.
warehouse is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
username and password are credentials of a Snowflake account attached to a role with the privileges outlined above. These credentials are not stored; they are used by Immuta to configure the integration.
role is a Snowflake role that has been granted the privileges outlined above.
Immuta will use the provided credentials to create a user called IMMUTA_SYSTEM_ACCOUNT
and grant the following privileges to that user:
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION
APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
Alternatively, you can use the manual setup method and edit the provided script to grant the Immuta system account OWNERSHIP
on the objects that Immuta will secure, instead of granting MANAGE GRANTS ON ACCOUNT
. The current role that has OWNERSHIP
on the securables will need to be granted to the Immuta system role. However, if granting OWNERSHIP
instead of MANAGE GRANTS ON ACCOUNT
, Immuta will not be able to manage the role that is granted to the account.
Response
The response returns the status of the Snowflake integration configuration connection. See the response schema reference for details about the response schema.
A successful response includes the validation tests statuses.
{
"id": "123456789",
"status": "creating",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Initial Validation: Basic Connection Test",
"status": "passed"
},
{
"name": "Initial Validation: Default Warehouse Access Test",
"status": "passed",
"result": []
},
{
"name": "Initial Validation: Validate access to Privileged Role",
"status": "passed",
"result": []
},
{
"name": "Validate Automatic: Database Does Not Exist",
"status": "passed"
},
{
"name": "Validate Automatic: Impersonation Role Does Not Exist",
"status": "skipped"
},
{
"name": "Validate Automatic Bootstrap User Grants",
"status": "passed"
}
]
}
}
Manual setup
To manually configure the integration, complete the following steps:
Generate the script
Select the tab below that matches your authentication method.
Copy the request example and replace the values with your own as directed to generate the script. The examples provided use JSON format, but the request also accepts YAML.
See the config object description for parameter definitions, value types, and additional configuration options.
curl -X 'POST' \
'https://www.organization.immuta.com/integrations/scripts/create' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"audit": {
"enabled": false,
},
"workspaces": {
"enabled": false
},
"impersonation": {
"enabled": false
},
"authenticationType": "userPassword",
"username": "[email protected]",
"password": "abc1234"
}
}'
Replace the Immuta URL and API key with your own.
Change the config values to your own, where
host is the URL of your Snowflake account.
warehouse is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
audit specifies whether query audit is enabled for Snowflake. See the object description for child parameters.
workspaces represents an Immuta project workspace configured for Snowflake. See the object description for child parameters.
impersonation specifies whether user impersonation is enabled. See the object description for child parameters.
username and password are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
Run the script returned in the response in your Snowflake environment. Running this script grants the following privileges to the Immuta system account:
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION
APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
Alternatively, you can grant the Immuta system account
OWNERSHIP
on the objects that Immuta will secure, instead of grantingMANAGE GRANTS ON ACCOUNT
. The current role that hasOWNERSHIP
on the securables will need to be granted to the Immuta system role. However, if grantingOWNERSHIP
instead ofMANAGE GRANTS ON ACCOUNT
, Immuta will not be able to manage the role that is granted to the account, so it is recommended to run the script as-is, without changes.
Response
The response returns the script for you to run in your environment.
Configure the integration in Immuta
Select the tab below that matches your authentication method.
Copy the request example and replace the values with your own as directed to configure the integration settings. The examples provided use JSON format, but the request also accepts YAML. The parameters and values you provide in this payload must match those you provided when generating the script.
See the config object description for parameter definitions, value types, and additional configuration options.
curl -X 'POST' \
'https://www.organization.immuta.com/integrations' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"audit": {
"enabled": false,
},
"workspaces": {
"enabled": false
},
"impersonation": {
"enabled": false
},
"authenticationType": "userPassword",
"username": "[email protected]",
"password": "abc1234"
}
}'
Replace the Immuta URL and API key with your own.
Pass the same payload you sent when generating the script, where
host is the URL of your Snowflake account.
warehouse is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
audit specifies whether query audit is enabled for Snowflake. See the object description for child parameters.
workspaces represents an Immuta project workspace configured for Snowflake. See the object description for child parameters.
impersonation specifies whether user impersonation is enabled. See the object description for child parameters.
username and password are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
Response
The response returns the status of the Snowflake integration configuration connection. See the response schema reference for details about the response schema.
A successful response includes the validation tests statuses.
{
"id": "123456789",
"status": "creating",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Initial Validation: Basic Connection Test",
"status": "passed"
},
{
"name": "Initial Validation: Default Warehouse Access Test",
"status": "passed",
"result": []
},
{
"name": "Initial Validation: Validate access to Privileged Role",
"status": "passed",
"result": []
},
{
"name": "Validate Automatic: Database Does Not Exist",
"status": "passed"
},
{
"name": "Validate Automatic: Impersonation Role Does Not Exist",
"status": "skipped"
},
{
"name": "Validate Automatic Bootstrap User Grants",
"status": "passed"
}
]
}
}
Get an integration
curl -X 'GET' \
'https://www.organization.immuta.com/integrations/{id}' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f'
Copy the request example.
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to get. Alternatively, you can get a list of all integrations and their IDs with the
GET /integrations
endpoint.
Response
The response returns the Snowflake integration configuration. See the response schema reference for details about the response schema. An unsuccessful request returns the status code and an error message. See the HTTP status codes and error messages for a list of statuses, error messages, and troubleshooting guidance.
{
"id": "123456789",
"status": "enabled",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Initial Validation: Basic Connection Test",
"status": "passed"
},
{
"name": "Initial Validation: Default Warehouse Access Test",
"status": "passed",
"result": []
},
{
"name": "Initial Validation: Validate access to Privileged Role",
"status": "passed",
"result": []
},
{
"name": "Validate Automatic: Database Does Not Exist",
"status": "passed"
},
{
"name": "Validate Automatic: Impersonation Role Does Not Exist",
"status": "skipped"
},
{
"name": "Validate Automatic Bootstrap User Grants",
"status": "passed"
}
]
},
"type": "Snowflake",
"autoBootstrap": true,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"port": 443,
"audit": {
"enabled": false,
},
"workspaces": {
"enabled": false
},
"impersonation": {
"enabled": false
},
"lineage": {
"enabled": false
},
"authenticationType": "userPassword",
"username": "<REDACTED>",
"password": "<REDACTED>",
"role": "ACCOUNTADMIN"
}
}
Get all integrations
Copy the request example.
Replace the Immuta URL and API key with your own.
curl -X 'GET' \
'https://www.organization.immuta.com/integrations' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f'
Response
The response returns the configuration for all integrations. See the response schema reference for details about the response schema. An unsuccessful request returns the status code and an error message. See the HTTP status codes and error messages for a list of statuses, error messages, and troubleshooting guidance.
[
{
"id": "1",
"status": "enabled",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Initial Validation: Basic Connection Test",
"status": "passed"
},
{
"name": "Initial Validation: Default Warehouse Access Test",
"status": "passed",
"result": []
},
{
"name": "Initial Validation: Validate access to Privileged Role",
"status": "passed",
"result": []
},
{
"name": "Validate Automatic: Database Does Not Exist",
"status": "passed"
},
{
"name": "Validate Automatic: Impersonation Role Does Not Exist",
"status": "skipped"
},
{
"name": "Validate Automatic Bootstrap User Grants",
"status": "passed"
}
]
},
"type": "Snowflake",
"autoBootstrap": true,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"port": 443,
"audit": {
"enabled": false
},
"workspaces": {
"enabled": false
},
"impersonation": {
"enabled": false
},
"lineage": {
"enabled": false
},
"authenticationType": "userPassword",
"username": "<REDACTED>",
"password": "<REDACTED>",
"role": "ACCOUNTADMIN"
}
},
{
"id": "2",
"status": "enabled",
"type": "Databricks",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Metastore validation",
"status": "passed"
},
{
"name": "Basic Connection Test",
"result": [
{
"1": 1
}
],
"status": "passed"
}
]
},
"autoBootstrap": true,
"config": {
"workspaceUrl": "www.example-workspace.cloud.databricks.com",
"httpPath": "sql/protocolv1/o/0/0000-00000-abc123",
"token": "REDACTED",
"audit": {
"enabled": false
},
"catalog": "immuta"
}
}
]
Update an integration configuration
You have two options for updating your integration. Follow the steps that match your initial configuration of autoBootstrap:
automatic update (autoBootstrap is
true
)manual update (autoBootstrap is
false
)
Automatic update
Select the section below that matches your authentication method.
Copy the request example and replace the values with your own as directed to update the integration settings. The examples provided use JSON format, but the request also accepts YAML.
See the config object description for parameter definitions, value types, and additional configuration options.
This request updates the configuration to enable query audit in Snowflake.
curl -X 'PUT' \
'https://www.organization.immuta.com/integrations/{id}' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
-d '{
"type": "Snowflake",
"autoBootstrap": true,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"audit": {
"enabled": true,
},
"authenticationType": "userPassword",
"username": "[email protected]",
"password": "abc1234",
"role": "ACCOUNTADMIN"
}
}'
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values to your own, where
host is the URL of your Snowflake account.
warehouse is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
audit specifies whether query audit is enabled for Snowflake. See the object description for child parameters.
username and password are credentials of a Snowflake account attached to a role with the privileges outlined above. These credentials are not stored; they are used by Immuta to enable or disable configuration settings.
role is a Snowflake role that has been granted the privileges outlined above.
Response
The response returns the status of the Snowflake integration configuration. See the response schema reference for details about the response schema.
A successful response includes the validation tests statuses.
{
"id": "123456789",
"status": "editing",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Initial Validation: Basic Connection Test",
"status": "passed"
},
{
"name": "Initial Validation: Default Warehouse Access Test",
"status": "passed",
"result": []
},
{
"name": "Initial Validation: Validate access to Privileged Role",
"status": "passed",
"result": []
},
{
"name": "Validate Automatic: Database Does Not Exist",
"status": "passed"
},
{
"name": "Validate Automatic: Impersonation Role Does Not Exist",
"status": "skipped"
},
{
"name": "Validate Automatic Bootstrap User Grants",
"status": "passed"
}
]
}
}
Manual update
To manually update the integration, complete the following steps:
Generate the updated script
Select the tab below that matches your authentication method.
Copy the request example and replace the values with your own as directed to generate the script. The examples provided use JSON format, but the request also accepts YAML.
See the config object description for parameter definitions, value types, and additional configuration options.
This request updates the configuration to enable query audit in Snowflake.
curl -X 'POST' \
'https://www.organization.immuta.com/integrations/{id}/scripts/edit' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"audit": {
"enabled": true
},
"workspaces": {
"enabled": false
},
"impersonation": {
"enabled": false
},
"authenticationType": "userPassword",
"username": "[email protected]",
"password": "abc1234"
}
}'
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values to your own, where
host is the URL of your Snowflake account.
warehouse is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
audit specifies whether query audit is enabled for Snowflake. See the object description for child parameters.
workspaces represents an Immuta project workspace configured for Snowflake. See the object description for child parameters.
impersonation specifies whether user impersonation is enabled. See the object description for child parameters.
username and password are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
Run the script returned in the response in your Snowflake environment.
Response
The response returns the script for you to run in your environment.
Update the integration in Immuta
Select the section below that matches your authentication method.
Copy the request example and replace the values with your own as directed to update the integration settings. The examples provided use JSON format, but the request also accepts YAML. The payload you provide must match the one you provided when generating the updated script.
See the config object description for parameter definitions, value types, and additional configuration options.
This request updates the configuration to enable query audit in Snowflake.
curl -X 'PUT' \
'https://www.organization.immuta.com/integrations/{id}' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "organization.us-east-1.snowflakecomputing.com",
"warehouse": "SAMPLE_WAREHOUSE",
"database": "SNOWFLAKE_SAMPLE_DATA",
"audit": {
"enabled": true
},
"workspaces": {
"enabled": false
},
"impersonation": {
"enabled": false
},
"authenticationType": "userPassword",
"username": "[email protected]",
"password": "abc1234"
}
}'
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Pass the same payload you sent when generating the script, where
host is the URL of your Snowflake account.
warehouse is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
audit specifies whether query audit is enabled for Snowflake. See the object description for child parameters.
workspaces represents an Immuta project workspace configured for Snowflake. See the object description for child parameters.
impersonation specifies whether user impersonation is enabled. See the object description for child parameters.
username and password are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
Response
The response returns the status of the Snowflake integration configuration. See the response schema reference for details about the response schema.
A successful response includes the validation tests statuses.
{
"id": "123456789",
"status": "editing",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Initial Validation: Basic Connection Test",
"status": "passed"
},
{
"name": "Initial Validation: Default Warehouse Access Test",
"status": "passed",
"result": []
},
{
"name": "Initial Validation: Validate access to Privileged Role",
"status": "passed",
"result": []
},
{
"name": "Validate Automatic: Database Does Not Exist",
"status": "passed"
},
{
"name": "Validate Automatic: Impersonation Role Does Not Exist",
"status": "skipped"
},
{
"name": "Validate Automatic Bootstrap User Grants",
"status": "passed"
}
]
}
}
Delete an integration
curl -X 'DELETE' \
'https://www.organization.immuta.com/integrations/{id}' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
-d '{
"authenticationType": "userPassword",
"username": "[email protected]",
"password": "abc1234",
"role": "ACCOUNTADMIN"
}'
Copy the request example.
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to delete.
If you set
autoBootstrap to
true
when enabling the integration, specify the authenticationType and the credentials you used to configure the integration in the payload, as illustrated in the example. See the Integrations API endpoints guide for details.autoBootstrap to
false
when enabling the integration,
Make the request above without including a payload to remove the integration from Immuta.
Run the generated script in Snowflake.
Cleaning up your Snowflake environment Until you manually run the cleanup script in your Snowflake environment, Immuta-managed roles and Immuta policies will still exist in Snowflake.
Response
The response returns the status of the Snowflake integration configuration that has been deleted. See the response schema reference for details about the response schema. An unsuccessful request returns the status code and an error message. See the HTTP status codes and error messages for a list of statuses, error messages, and troubleshooting guidance.
{
"id": "123456789",
"status": "deleting",
"validationResults": {
"status": "passed",
"validationTests": [
{
"name": "Initial Validation: Basic Connection Test",
"status": "passed"
},
{
"name": "Initial Validation: Default Warehouse Access Test",
"status": "passed",
"result": []
},
{
"name": "Initial Validation: Validate access to Privileged Role",
"status": "passed",
"result": []
},
{
"name": "Validate Automatic: Database Does Not Exist",
"status": "passed"
},
{
"name": "Validate Automatic: Impersonation Role Does Not Exist",
"status": "skipped"
},
{
"name": "Validate Automatic Bootstrap User Grants",
"status": "passed"
}
]
}
}
Last updated
Was this helpful?