1 of 1

Configure a Snowflake Integration

Support for this endpoint is only available using this legacy Snowflake workflow. .

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

configure a Snowflake integration
get a Snowflake integration

Requirements

APPLICATION_ADMIN Immuta permission
The Snowflake user running the installation, edit, or delete script must have the following privileges:

Configure the integration

You have two options for configuring your Snowflake integration:

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

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 for parameter definitions, value types, and additional configuration options.

Replace the Immuta URL and with your own.
Change the config values to your own, where
- host is the URL of your Snowflake account.

Response

The response returns the status of the Snowflake integration configuration connection. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

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 for parameter definitions, value types, and additional configuration options.

Replace the Immuta URL and with your own.
Change the config values to your own, where
- host is the URL of your Snowflake account.

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 .

See the for parameter definitions, value types, and additional configuration options.

Replace the Immuta URL and with your own.
Pass the same payload you sent when , where
- host is the URL of your Snowflake account.

Response

The response returns the status of the Snowflake integration configuration connection. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Get an integration

Copy the request example.
Replace the Immuta URL and 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 .

Response

The response returns the Snowflake integration configuration. See the for details about the response schema. An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Get all integrations

Copy the request example.
Replace the Immuta URL and with your own.

Response

The response returns the configuration for all integrations. See the for details about the response schema. An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Update an integration configuration

You have two options for updating your integration. Follow the steps that match your initial configuration of autoBootstrap:

(autoBootstrap is true)
(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 for parameter definitions, value types, and additional configuration options.

This request updates the configuration to enable query audit in Snowflake.

Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the

Response

The response returns the status of the Snowflake integration configuration. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

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 for parameter definitions, value types, and additional configuration options.

This request updates the configuration to enable query audit in Snowflake.

Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config

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 .

See the for parameter definitions, value types, and additional configuration options.

This request updates the configuration to enable query audit in Snowflake.

Replace the Immuta URL and 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

Response

The response returns the status of the Snowflake integration configuration. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Enable or edit impersonation for an existing integration

You can enable impersonation for an existing Snowflake integration or edit the impersonation role name for an existing integration. Select one of the tabs below for guidance.

If enabling impersonation for the first time, create the impersonation role in Snowflake:
Update the integration:
1. Replace the Immuta URL and with your own.

Response

The response returns the status of the Snowflake integration configuration. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Delete an integration

Copy the request example.
Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to delete.

Response

The response returns the status of the Snowflake integration configuration that has been deleted. See the for details about the response schema. An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Configure a Snowflake Integration

Support for this endpoint is only available using this legacy Snowflake workflow. .

Use the /integrations endpoint to

configure a Snowflake integration
get a Snowflake integration

Requirements

APPLICATION_ADMIN Immuta permission
The Snowflake user running the installation, edit, or delete script must have the following privileges:

Configure the integration

You have two options for configuring your Snowflake integration:

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

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 for parameter definitions, value types, and additional configuration options.

Replace the Immuta URL and with your own.
Change the config values to your own, where
- host is the URL of your Snowflake account.

Response

The response returns the status of the Snowflake integration configuration connection. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

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 for parameter definitions, value types, and additional configuration options.

Replace the Immuta URL and with your own.
Change the config values to your own, where
- host is the URL of your Snowflake account.

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 .

See the for parameter definitions, value types, and additional configuration options.

Replace the Immuta URL and with your own.
Pass the same payload you sent when , where
- host is the URL of your Snowflake account.

Response

The response returns the status of the Snowflake integration configuration connection. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Get an integration

Copy the request example.
Replace the Immuta URL and 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 .

Response

Get all integrations

Copy the request example.
Replace the Immuta URL and with your own.

Response

Update an integration configuration

You have two options for updating your integration. Follow the steps that match your initial configuration of autoBootstrap:

(autoBootstrap is true)
(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 for parameter definitions, value types, and additional configuration options.

This request updates the configuration to enable query audit in Snowflake.

Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the

Response

The response returns the status of the Snowflake integration configuration. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

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 for parameter definitions, value types, and additional configuration options.

This request updates the configuration to enable query audit in Snowflake.

Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config

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 .

See the for parameter definitions, value types, and additional configuration options.

This request updates the configuration to enable query audit in Snowflake.

Replace the Immuta URL and 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

Response

The response returns the status of the Snowflake integration configuration. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Enable or edit impersonation for an existing integration

You can enable impersonation for an existing Snowflake integration or edit the impersonation role name for an existing integration. Select one of the tabs below for guidance.

If enabling impersonation for the first time, create the impersonation role in Snowflake:
Update the integration:
1. Replace the Immuta URL and with your own.

Response

The response returns the status of the Snowflake integration configuration. See the for details about the response schema.

A successful response includes the validation tests statuses.

An unsuccessful request returns the status code and an error message. See the for a list of statuses, error messages, and troubleshooting guidance.

Delete an integration

Copy the request example.
Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to delete.

Response

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": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'

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 is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
- privateKey is your private key. If you are using curl, 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.
- connectArgs is used to set PRIV_KEY_FILE_PWD if the private key is encrypted.

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

Alternatively, you can use the 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.

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": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'

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 for child parameters.
- workspaces represents an Immuta project workspace configured for Snowflake. See the for child parameters.
- impersonation specifies whether user impersonation is enabled. See the for child parameters. Once you finish configuring the integration, you can grant the IMPERSONATE_USER permission to Immuta users. See the for instructions.
- username is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
- privateKey is your private key. If you are using curl, 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.
- connectArgs is used to set PRIV_KEY_FILE_PWD if the private key is encrypted.
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

In this example, Snowflake External OAuth is used to authenticate the system account user, ensuring secure communication between Immuta and Snowflake. To use this authentication method, autoBootstrap must be false.

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",
      "impersonation": {
        "enabled": true,
        "role": "IMMUTA_IMPERSONATION"
      },
      "audit": {
        "enabled": false
      },
      "workspaces": {
        "enabled": true,
        "warehouses": ["SAMPLE_WAREHOUSE"]
      },
      "authenticationType": "oAuthClientCredentials",
      "oAuthClientConfig": {
        "provider": "Okta",
        "clientId": "123456abc",
        "useCertificate": false,
        "clientSecret": "secret",
        "authorityUrl": "example.authority.com"
      }
    }
    }'

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 for child parameters.
- workspaces.enabled specifies whether Immuta project workspaces are enabled for Snowflake.
- workspaces.warehouses is a list of warehouses that workspace users have usage privileges on.
- impersonation specifies whether user impersonation is enabled. See the for child parameters. Once you finish configuring the integration, you can grant the IMPERSONATE_USER permission to Immuta users. See the for instructions.
- username is the system account user that can act on Snowflake objects and configure the integration.
- oAuthClientConfig specifies your provider, client ID, client secret, authority URL, and your encoded public and private keys. See the for details about child parameters.
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

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": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'

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 for child parameters.
- workspaces represents an Immuta project workspace configured for Snowflake. See the for child parameters.
- impersonation specifies whether user impersonation is enabled. See the for child parameters. Once you finish configuring the integration, you can grant the IMPERSONATE_USER permission to Immuta users. See the for instructions.
- username is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
- privateKey is your private key. If you are using curl, 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.
- connectArgs is used to set PRIV_KEY_FILE_PWD if the private key is encrypted.