Book a demo

Register a Snowflake Connection

Connections allow you to register your data objects in a technology through a single connection, instead of registering data sources and an integration separately.

This feature is enabled by default on all tenants created post February 26, 2025 and available to select tenants created prior. Contact your Immuta representative to enable this feature.

The connection API is a REST API which allows users to register a Snowflake to Immuta with a single set of credentials rather than configuring an integration and creating data sources separately. Then Immuta can manage and enforce access controls on your data through that connection. To manage your connection, see the Manage a connection reference guide.

Requirements

The following permissions and personas are used in the registration process:

  • Immuta permission: APPLICATION_ADMIN

  • The Snowflake user registering the connection and running the script 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

Prerequisites

No Snowflake integration configured in Immuta. If your Snowflake integration is already configured on the app settings page, follow the Use the connection upgrade manager guide.

Complete the following steps to register a Snowflake connection:

  1. Create an Immuta system account with the proper Snowflake privileges for Immuta to use to manage policies in Snowflake.

  2. Use the /integrations/scripts/create endpoint to receive a script.

  3. Run the script in Snowflake.

  4. Use the /data/connection endpoint to finish registering your connection in Immuta.

Step 1: Set up the Immuta system account

Complete the following actions in Snowflake:

  1. Create a new user in Snowflake to be the Immuta system account. Immuta will use this system account continuously to orchestrate Snowflake policies and maintain state between Immuta and Snowflake.

  2. Create a Snowflake role with a minimum of the following privileges:

    • USAGE on all databases and schemas with registered data sources.

    • REFERENCES on all tables and views registered in Immuta.

    • .

  3. Grant the new Snowflake role to the system account you just created.

Step 2: Generate the script

POST /integrations/scripts/create

  1. Using the example request, update the <placeholder_values> with your connection details and the authentication credentials for the system account you just created.

  2. Copy the config object to use later in the setup process.

  3. Run the request.

  4. Copy the returned script and use it in the next step.

Find descriptions of the editable attributes in the table below and of the full payload in the Integration configuration payload reference guide.

curl -X 'POST' \
    'https://<your-immuta-url>/integrations/scripts/create' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: <your-bearer-token>' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "<your-Snowflake-hostname-url>",
      "warehouse": "<your-Snowflake-warehouse>",
      "database": "<your-Snowflake-database>",
      "authenticationType": "userPassword",
      "username": "<new-Snowflake-username>",
      "password": "<new-Snowflake-password>",
      "audit": {"enabled": true},
      "workspaces": {"enabled": false},
      "impersonation": {"enabled": false},
      "lineage": { "enabled": false },
      "userRolePattern": { "exclude": [] }
    }
    }'

Payload parameters

Attribute
Description
Required

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

config.username string

The new username of the system account that can act on Snowflake objects and register the connection.

Yes

config.password string

The password of the system account that can act on Snowflake objects and register the connection.

Yes

config.audit object

This object enables Snowflake query audit.

No

config.audit.enabled boolean

If true, Snowflake query audit is enabled. Set to true for the recommended configuration.

No

config.workspaces object

This object represents an Immuta project workspace configured for Snowflake.

No

config.workspaces.enabled boolean

If true, Snowflake project workspaces are enabled. If you use Snowflake table grants, set to false because table grants and project workspaces cannot be used together. Set to false for the recommended configuration.

No

config.impersonation object

This object enables user impersonation.

No

config.impersonation.enabled boolean

If true, user impersonation is enabled. If you use Snowflake low row access policy mode, set to false because that mode and impersonation cannot be used together.

No

config.lineage object

This object enables Snowflake lineage ingestion.

No

config.lineage.enabled boolean

If true, Snowflake lineage is enabled. Set false for the recommended configuration.

No

config.userRolePattern object

This object excludes roles and users from authorization checks.

No

config.userRolePattern.exclude array

This array is a list of roles and users (both case-sensitive) to exclude from authorization checks. Wildcards are unsupported. The roles and users will not have policies applied to them when querying Immuta protected Snowflake tables.

No

Step 3: Run the script in Snowflake

Using your generated script, run it in your Snowflake environment as a user with the permissions listed in the requirements section.

The script will use the provided Immuta system user credentials to create the database you specified in the earlier step and set up Immuta-managed resources in Snowflake.

Step 4: Create the connection in Immuta

POST /data/connection

Using the tabs below, copy the request and update the <placeholder_values> with your connection details. The connection details here should match the ones used when generating the script, and the payload from the script generation should be pasted exactly into nativeIntegration. Then submit the request.

Find descriptions of the editable attributes in the table below and of the full payload in the Connection registration payloads reference guide. The recommended setting values are included in the example.

Test run

Opt to test and validate the create connection payload using a dry run:

POST /data/connection/test

curl -X 'POST' \
    'https://<your-immuta-url>/data/connection' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: <your-bearer-token>' \
    -d '{
     "connectionKey": "<your-connection-key-name>",
     "connection": {
       "technology": "Snowflake",
       "hostname": "<your-Snowflake-hostname-url>",
       "port": <your-Snowflake-port>,
       "warehouse": "<your-Snowflake-warehouse>",
       "role": "<your-Snowflake-role>",
       "authenticationType": "userPassword",
       "username": "<your-Snowflake-username>",
       "password": "<your-Snowflake-password>",
     },
     "settings": {
         "isActive": false
     },
     "options": {
       "forceRecursiveCrawl": true
     },
     "nativeIntegration": {
       "type": "Snowflake",
       "autoBootstrap": false,
       "config": {
         "authenticationType": "userPassword",
         "username": "<your-Snowflake-username>",
         "password": "<your-Snowflake-password>",
         "host": "<your-Snowflake-hostname-url>",
         "port": <your-Snowflake-port>,
         "warehouse": "<your-Snowflake-warehouse>",
         "database": "<your-Snowflake-database>",
         "impersonation": { "enabled": false },
         "audit": { "enabled": true },
         "workspaces": { "enabled": false },
         "lineage": { "enabled": false },
         "userRolePattern": { "exclude": [] }
       }
     }
    }'

Payload parameters

Attribute
Description
Required

connectionKey string

A unique name for the 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 should be the same as nativeIntegration.config.host.

Yes

connection.port integer

The port to use when registering your Snowflake connection. 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 registering the Snowflake connection. 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 register the connection.

Yes

connection.password string

The password of the system account that can act on Snowflake objects and register the connection.

Yes

settings array

Specifications of the connection's settings, including status.

No

settings.isActive boolean

When false, data objects will be inactive (disabled) by default when created in Immuta. Set to false for the recommended configuration.

No

options.forceRecursiveCrawl boolean

If false, only active (enabled) objects will be crawled. If true, both active (enabled) and inactive (disabled) data objects will be crawled; any child objects from inactive (disabled) objects will be set as inactive (disabled). Set to true for the recommended configuration.

No

nativeIntegration object

Configuration attributes that should match the values used when getting the script from the integration endpoint. See the table above for descriptions.

Yes

Response schema

Attribute
Description

objectPath string

The list of names that uniquely identify the path to a data object in the remote platform's hierarchy. The first element will 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.

Example response

{
  "objectPath": ['<your-connection-key-name>'],
  "bulkId": "a-new-uuid"
}
PreviousRegister a ConnectionNextRegister a Databricks Unity Catalog Connection

Last updated

Was this helpful?