1 of 7

How-to Guides

The how-to guides in this section illustrate how to integrate your remote data platform with Immuta so you can manage and enforce access controls on your data.

Immuta generates policy-enforced views in your configured Redshift schema for tables registered as Immuta data sources.

Follow this guide to configure and manage your Amazon Redshift Spectrum integration. Example requests and responses are provided throughout the guide so that you can quickly copy and update them with your own settings.

Private preview: This integration is available to select accounts. Contact your Immuta representative for details.

Immuta's Amazon S3 integration allows users to apply subscription policies to data in S3 to restrict what prefixes, buckets, or objects users can access. To enforce access controls on this data, Immuta creates S3 grants that are administered by S3 Access Grants, an AWS feature that defines access permissions to data in S3.

Follow this guide to configure and manage your Amazon S3 integration. Example requests and responses are provided throughout the guide so that you can quickly copy and update them with your own settings.

In this integration, Immuta generates policy-enforced views in a schema in your configured Azure Synapse Analytics Dedicated SQL pool for tables registered as Immuta data sources.

Follow this guide to configure and manage your Azure Synapse Analytics integration. Example requests and responses are provided throughout the guide so that you can quickly copy and update them with your own settings.

Immuta’s integration with Unity Catalog allows you to manage multiple Databricks workspaces through Unity Catalog while protecting your data with Immuta policies. Instead of manually creating UDFs or granting access to each table in Databricks, you can author your policies in Immuta and have Immuta manage and enforce Unity Catalog access-control policies on your data in Databricks clusters or SQL warehouses.

Follow this guide to configure and manage your Databricks Unity Catalog integration. Example requests and responses are provided throughout the guide so that you can quickly copy and update them with your own settings.

In this integration, Immuta generates policy-enforced views in your configured Google BigQuery dataset for tables registered as Immuta data sources.

Follow this guide to configure and manage your Google BigQuery integration. Example requests and responses are provided throughout the guide so that you can quickly copy and update them with your own settings.

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.

Follow this guide to configure and manage your Snowflake integration. Example requests and responses are provided throughout the guide so that you can quickly copy and update them with your own settings.

Immuta policies are translated into Starburst rules and permissions and applied directly to tables within users’ existing catalogs.

Follow this guide to configure and manage your Starburst (Trino) integration. Example requests and responses are provided throughout the guide so that you can quickly copy and update them with your own settings.

Configure an Amazon Redshift Spectrum Integration

Use the API to set up your Amazon Redshift Spectrum integration

In the Amazon Redshift Spectrum integration, Immuta generates policy-enforced views in your configured Redshift schema for tables registered as Immuta data sources.

Use the /integrations endpoint to

configure an Amazon Redshift Spectrum integration
get an Amazon Redshift Spectrum integration

A Redshift cluster with an AWS row-level security patch applied. for guidance.
that is .
The must be set to false (default setting) for your Redshift cluster.

The user configuring the integration must have the permissions below.

APPLICATION_ADMIN Immuta permission
The Redshift role used to run the Immuta bootstrap script must have the following privileges when configuring the integration:
- If using an existing database

To configure the integration, complete the following steps:

You have two options for setting up the database Immuta will use to manage the integration and enforce policies:

Configure the integration with an existing database that contains the external tables. When configuring the integration, specify an existing database in Amazon Redshift as the database in which Immuta will add the Immuta-managed schemas and views.
If using an existing database, the Redshift role used to run the Immuta bootstrap script must have the following privileges:
- ALL PRIVILEGES ON DATABASE for the database you configure the integration with, as you must manage grants on that database.

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Change the config values to your own, where

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

Response

The response returns the script for you to run in the existing or new database you created for the Immuta system user.

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Pass the same payload you sent when , where

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

The response returns the status of the Amazon Redshift Spectrum 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.

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 .

The response returns an Amazon Redshift Spectrum 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.

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

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.

To update the integration, complete the following steps:

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.

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

Response

The response returns the script for you to run in your Amazon Redshift environment.

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.

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

The response returns the status of the Amazon Redshift Spectrum 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.

Use the script endpoint (for integrations that were not successfully created) or the endpoint (for integrations that were successfully created) to remove Immuta-managed resources from your Amazon Redshift environment.
Copy the request example.
Replace the Immuta URL and with your own.

The response returns the status of the Amazon Redshift Spectrum 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 an Amazon S3 Integration

Use the API to set up your Amazon S3 integration

Private preview: This integration is available to select accounts. Contact your Immuta representative for details.

The Amazon S3 resource allows you to create, configure, and manage your S3 integration. In this integration, Immuta provides coarse-grained access controls for data in S3 by performing permission grants using the Access Grants API so that users don't have to manage individual IAM policies themselves.

Use the /integrations endpoint to

configure an Amazon S3 integration

S3 integration enabled in Immuta; contact your Immuta representative to enable this integration
; contact your Immuta representative to get this feature enabled
No location is registered in your AWS Access Grants instance before configuring the integration in Immuta

APPLICATION_ADMIN Immuta permission to configure the integration
CREATE_S3_DATASOURCE Immuta permission to register S3 prefixes
There are two AWS roles that you will set up in AWS before configuring the integration in Immuta:

. AWS supports one Access Grants instance per region per AWS account.
Create a permissions policy with the following permissions. You will attach this permissions policy to your location IAM role once created.
If you use server-side encryption with AWS Key Management Service (AWS KMS) keys to encrypt your data, the following permissions are required for the IAM role in the policy. If you do not use this feature, do not include these permissions in your IAM policy:

role and select AWS account as the trusted entity type.
Edit the trust policy to give the S3 Access Grants service principal access to this role in the resource policy file.
The trust policy for this role should include at least the permissions provided in the example below, but might need additional permissions depending on other local setup factors.
Attach the permissions policy you created in the previous step to this IAM role to grant the permissions to the role. Once you begin configuring the integration in Immuta, you will add this role to your integration configuration so that Immuta can register this role with your Access Grants location.

Create a permissions policy with the permissions in the sample policy below.
Replace <location_role_arn> and <access_grants_instance_arn> in the example below with the ARNs of the location IAM role you created and your Access Grants instance, respectively. The Access Grants instance resource ARN should be scoped to apply to any future locations that will be created under this Access Grants instance. For example, "Resource": "arn:aws:s3:us-east-2:6********499:access-grants/default*" ensures that the role would have permissions for both of these locations:
1. arn:aws:s3:us-east-2:6********499:access-grants/default/newlocation1

This request configures the integration using the AWS access key authentication method.

Copy the request example. The example uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Change the config values to your own, where

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

The response returns the status of the S3 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.

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 .

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

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

Copy the request example, and replace the values with your own as directed to update the integration settings. The example provided uses 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.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values from above to your own. The editable values listed below are the only parameters that can change from the integration's existing configuration. The required parameters listed below must match the integration's existing configuration.

The response returns the status of the Amazon S3 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.

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.

The response returns the status of the S3 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 Google BigQuery View-Based Integration

Use the API to set up your Google BigQuery view-based integration

Private preview: This integration is available to all accounts.

The Google BigQuery resource allows you to create, configure, and manage your Google BigQuery view-based integration. In this integration, Immuta generates policy-enforced views in your configured Google BigQuery dataset for tables registered as Immuta data sources.

Use the /integrations endpoint to

configure a Google BigQuery view-based integration
get a Google BigQuery view-based integration

APPLICATION_ADMIN Immuta permission
Google BigQuery view-based integration enabled in Immuta (work with your Immuta representative to enable this integration)
To execute the Immuta script from your command line to , you must be authenticated to the gcloud CLI utility as a user with all of the following roles:

by either using the Google Cloud console or the provided Immuta script.

Copy the request example. The example uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Change the config values to your own, where

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

The response returns the status of the 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.

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 .

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

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

Copy the request example, which updates the private key. The example uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.

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

The response returns the status of the 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.

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.

The response returns the status of the 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 Starburst (Trino) Integration

Deprecation notice

Support for configuring the Starburst (Trino) integration using this legacy workflow has been deprecated. Instead, configure your integration and register your data using .

The Starburst (Trino) resource allows you to create and manage your Starburst (Trino) integration. In this integration, Immuta policies are translated into Starburst rules and permissions and applied directly to tables within users’ existing catalogs.

Use the /integrations endpoint to

configure a Starburst (Trino) integration
get a Starburst (Trino) integration

APPLICATION_ADMIN Immuta permission
A valid

To configure the Starburst (Trino) integration, complete the following steps:

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.

The response returns the status of the Starburst (Trino) 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.

Navigate to the Immuta App Settings page and click the Integrations tab.
Click your enabled Starburst (Trino) integration and copy the configuration snippet displayed.
Follow the steps in the to add the configuration in the appropriate immuta-access-control.properties file to finish configuring your cluster.

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 .

The response returns a Starburst (Trino) integration configuration and the Immuta API key used to configure the Starburst cluster. 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.

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

.
Copy the request example below and replace these values:
- Replace the Immuta URL and with your own.

The response includes your new Immuta API key.

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.

The response returns the status of the Starburst (Trino) 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.

{ "id": "123456789", "status": "creating", "validationResults": { "status": "passed", "validationTests": [ { "name": "Basic Validation: Verify service account not being used for data source connection credentials", "status": "passed" }, { "name": "Basic Validation: Immuta Service Account postfix", "status": "passed" }, { "name": "Basic Validation: Non-matching service account in key file", "status": "passed" }, { "name": "Basic Validation: Connection can be made to BigQuery", "status": "passed" }, { "name": "Initialize Validation: [Dataset - exists] innate-conquest-123456.immuta", "status": "passed" }, { "name": "Validate Manual: [Dataset - create] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144", "status": "passed" }, { "name": "Validate Manual: [Table - create] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "passed" }, { "name": "Validate Manual: [Table - insert] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "warning", "message": "Billing has not been enabled for this project. Enable billing at https://console.cloud.google.com/billing. DML queries are not allowed in the free tier. Set up a billing account to remove this restriction. Confirm that the bootstrap script was executed without any modifications. This warning will not prevent the connection but continue at your own risk as some features may not function." }, { "name": "Validate Manual: [Table - get] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE (After insert)", "status": "skipped" }, { "name": "Validate Manual: [Table - update] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "skipped" }, { "name": "Validate Manual: [Table - get] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE (After update)", "status": "skipped" }, { "name": "Validate Manual: [Table - delete] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "passed" }, { "name": "Validate Manual: [Dataset - delete] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144", "status": "passed" } ] } }

{ "id": "123456789", "status": "enabled", "validationResults": { "status": "passed", "validationTests": [ { "name": "Basic Validation: Verify service account not being used for data source connection credentials", "status": "passed" }, { "name": "Basic Validation: Immuta Service Account postfix", "status": "passed" }, { "name": "Basic Validation: Non-matching service account in key file", "status": "passed" }, { "name": "Basic Validation: Connection can be made to BigQuery", "status": "passed" }, { "name": "Initialize Validation: [Dataset - exists] innate-conquest-123456.immuta", "status": "passed" }, { "name": "Validate Manual: [Dataset - create] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144", "status": "passed" }, { "name": "Validate Manual: [Table - create] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "passed" }, { "name": "Validate Manual: [Table - insert] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "warning", "message": "Billing has not been enabled for this project. Enable billing at https://console.cloud.google.com/billing. DML queries are not allowed in the free tier. Set up a billing account to remove this restriction. Confirm that the bootstrap script was executed without any modifications. This warning will not prevent the connection but continue at your own risk as some features may not function." }, { "name": "Validate Manual: [Table - get] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE (After insert)", "status": "skipped" }, { "name": "Validate Manual: [Table - update] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "skipped" }, { "name": "Validate Manual: [Table - get] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE (After update)", "status": "skipped" }, { "name": "Validate Manual: [Table - delete] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "passed" }, { "name": "Validate Manual: [Dataset - delete] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144", "status": "passed" } ] }, "type": "Google BigQuery", "autoBootstrap": false, "config": { "port": 443, "role": "immuta", "datasetSuffix": "_secureView", "dataset": "immuta", "location": "us-east-1", "credential": { "type": "service_account", "project_id": "innate-conquest-123456", "private_key_id": "9163c12345690924f5dd218ff39", "private_key": "-----BEGIN PRIVATE KEY-----\nXXXXXXXro0s\n/yQlPQijowkccmrmWJyr93kdLnwJzBvLHCto/+W\ncvF2ygX9oM/dyUK//z\//4nptMp+Ck//Yw3D4rIBwGu4DWiR1qRnf\nDoGyXfThPTQ==\n-----END PRIVATE KEY-----\n", "client_email": "service-account-id@innate-conquest-123456.iam.gserviceaccount.com", "client_id": "1166290***432952487857", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/service-account-id%40innate-conquest-123456.iam.gserviceaccount.com", "universe_domain": "googleapis.com" } } }

{ "id": "123456789", "status": "editing", "validationResults": { "status": "passed", "validationTests": [ { "name": "Basic Validation: Verify service account not being used for data source connection credentials", "status": "passed" }, { "name": "Basic Validation: Immuta Service Account postfix", "status": "passed" }, { "name": "Basic Validation: Non-matching service account in key file", "status": "passed" }, { "name": "Basic Validation: Connection can be made to BigQuery", "status": "passed" }, { "name": "Initialize Validation: [Dataset - exists] innate-conquest-123456.immuta", "status": "passed" }, { "name": "Validate Manual: [Dataset - create] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144", "status": "passed" }, { "name": "Validate Manual: [Table - create] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "passed" }, { "name": "Validate Manual: [Table - insert] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "warning", "message": "Billing has not been enabled for this project. Enable billing at https://console.cloud.google.com/billing. DML queries are not allowed in the free tier. Set up a billing account to remove this restriction. Confirm that the bootstrap script was executed without any modifications. This warning will not prevent the connection but continue at your own risk as some features may not function." }, { "name": "Validate Manual: [Table - get] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE (After insert)", "status": "skipped" }, { "name": "Validate Manual: [Table - update] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "skipped" }, { "name": "Validate Manual: [Table - get] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE (After update)", "status": "skipped" }, { "name": "Validate Manual: [Table - delete] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144.IMMUTA_VERIFY_TABLE", "status": "passed" }, { "name": "Validate Manual: [Dataset - delete] innate-conquest-123456.IMMUTA_VERIFY_DATASET_144", "status": "passed" } ] } }

Configure an Amazon Redshift Spectrum Integration

Use the API to set up your Amazon Redshift Spectrum integration

In the Amazon Redshift Spectrum integration, Immuta generates policy-enforced views in your configured Redshift schema for tables registered as Immuta data sources.

Use the /integrations endpoint to

configure an Amazon Redshift Spectrum integration
get an Amazon Redshift Spectrum integration

A Redshift cluster with an AWS row-level security patch applied. for guidance.
that is .
The must be set to false (default setting) for your Redshift cluster.

The user configuring the integration must have the permissions below.

APPLICATION_ADMIN Immuta permission
The Redshift role used to run the Immuta bootstrap script must have the following privileges when configuring the integration:
- If using an existing database

To configure the integration, complete the following steps:

You have two options for setting up the database Immuta will use to manage the integration and enforce policies:

Configure the integration with an existing database that contains the external tables. When configuring the integration, specify an existing database in Amazon Redshift as the database in which Immuta will add the Immuta-managed schemas and views.
If using an existing database, the Redshift role used to run the Immuta bootstrap script must have the following privileges:
- ALL PRIVILEGES ON DATABASE for the database you configure the integration with, as you must manage grants on that database.

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Change the config values to your own, where

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

Response

The response returns the script for you to run in the existing or new database you created for the Immuta system user.

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Pass the same payload you sent when , where

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

The response returns the status of the Amazon Redshift Spectrum 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.

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 .

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

To update the integration, complete the following steps:

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.

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

Response

The response returns the script for you to run in your Amazon Redshift environment.

Copy the request example. The example provided uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.

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

The response returns the status of the Amazon Redshift Spectrum 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.

Use the script endpoint (for integrations that were not successfully created) or the endpoint (for integrations that were successfully created) to remove Immuta-managed resources from your Amazon Redshift environment.
Copy the request example.
Replace the Immuta URL and with your own.

Configure an Amazon S3 Integration

Use the API to set up your Amazon S3 integration

Private preview: This integration is available to select accounts. Contact your Immuta representative for details.

Use the /integrations endpoint to

configure an Amazon S3 integration

S3 integration enabled in Immuta; contact your Immuta representative to enable this integration
; contact your Immuta representative to get this feature enabled
No location is registered in your AWS Access Grants instance before configuring the integration in Immuta

APPLICATION_ADMIN Immuta permission to configure the integration
CREATE_S3_DATASOURCE Immuta permission to register S3 prefixes
There are two AWS roles that you will set up in AWS before configuring the integration in Immuta:

. AWS supports one Access Grants instance per region per AWS account.
Create a permissions policy with the following permissions. You will attach this permissions policy to your location IAM role once created.
If you use server-side encryption with AWS Key Management Service (AWS KMS) keys to encrypt your data, the following permissions are required for the IAM role in the policy. If you do not use this feature, do not include these permissions in your IAM policy:

role and select AWS account as the trusted entity type.
Edit the trust policy to give the S3 Access Grants service principal access to this role in the resource policy file.
The trust policy for this role should include at least the permissions provided in the example below, but might need additional permissions depending on other local setup factors.
Attach the permissions policy you created in the previous step to this IAM role to grant the permissions to the role. Once you begin configuring the integration in Immuta, you will add this role to your integration configuration so that Immuta can register this role with your Access Grants location.

Create a permissions policy with the permissions in the sample policy below.
Replace <location_role_arn> and <access_grants_instance_arn> in the example below with the ARNs of the location IAM role you created and your Access Grants instance, respectively. The Access Grants instance resource ARN should be scoped to apply to any future locations that will be created under this Access Grants instance. For example, "Resource": "arn:aws:s3:us-east-2:6********499:access-grants/default*" ensures that the role would have permissions for both of these locations:
1. arn:aws:s3:us-east-2:6********499:access-grants/default/newlocation1

This request configures the integration using the AWS access key authentication method.

Copy the request example. The example uses JSON format, but the request also accepts YAML.
Replace the Immuta URL and with your own.
Change the config values to your own, where

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

The response returns the status of the S3 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.

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 .

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

Copy the request example, and replace the values with your own as directed to update the integration settings. The example provided uses 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.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values from above to your own. The editable values listed below are the only parameters that can change from the integration's existing configuration. The required parameters listed below must match the integration's existing configuration.

The response returns the status of the Amazon S3 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.

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.

[ { "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": "123456789", "status": "enabled", "validationResults": { "status": "passed", "validationTests": [ { "name": "There is no existing integration matching this configuration", "status": "passed" }, { "name": "The provided integration name is unique across Immuta S3 integrations", "status": "passed" }, { "name": "The provided access grants location role is a valid ARN format", "status": "passed" }, { "name": "The provided AWS credentials allow fetching the caller's identity via the AWS STS API", "status": "passed" }, { "name": "An AWS Access Grants instance is configured in the provided AWS account and region", "status": "passed" }, { "name": "The provided S3 path exists and Immuta can list prefixes", "status": "passed" }, { "name": "An AWS Access Grants location does not yet exist for the provided path", "status": "passed" } ] }, "type": "Native S3", "autoBootstrap": false, "config": { "port": 443, "name": "S3 integration", "awsAccountId": "123456789", "awsRegion": "us-east-1", "awsLocationRole": "arn:aws:iam::123456789:role/access-grants-instance-role", "awsLocationPath": "s3://", "authenticationType": "accessKey", "awsAccessKeyId": "123456789", "awsSecretAccessKey": "123456789" } } ]

Configure an Azure Synapse Analytics Integration

Use the API to set up your Azure Synapse Analytics integration

The Azure Synapse Analytics resource allows you to create, configure, and manage your Azure Synapse Analytics integration. In this integration, Immuta generates policy-enforced views in a schema in your configured Azure Synapse Analytics Dedicated SQL pool for tables registered as Immuta data sources.

Use the /integrations endpoint to

configure an Azure Synapse Analytics integration

APPLICATION_ADMIN Immuta permission
A running Dedicated SQL pool
Account used to configure or edit the integration must have the Azure Synapse Analytics permission to manage GRANTS

You have two options for configuring your Azure Synapse Analytics integration:

: Grant Immuta one-time use of credentials to automatically configure your Azure Synapse Analytics environment and the integration. When performing an automated installation, Immuta requires temporary, one-time use of credentials with the permission to manage GRANTS.
: Run the Immuta script in your Azure Synapse Analytics environment yourself to configure your environment and the integration. The specified role used to run the bootstrap needs to have the permission to manage GRANTS.

Copy the request example from one of the tabs below, 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 Azure Synapse Analytics account.

The response returns the status of the Azure Synapse Analytics 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.

To manually configure the integration, complete the following steps:

Note: This script is not required when using the OAuth authentication method. Go to the next step.

Copy the request example from one of the tabs below, 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 Azure Synapse Analytics account.

Response

The response returns the script for you to run in your environment.

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 Azure Synapse Analytics account.

Response

The response returns the script for you to run in your environment.

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 Azure Synapse Analytics account.

The response returns the status of the Azure Synapse Analytics 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.

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 .

The response returns an Azure Synapse Analytics 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.

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

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

(autoBootstrap is true)
(autoBootstrap is false)

Copy the request example, and replace the values with your own as directed to update the integration settings. The example provided uses 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.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values to your own, where

The response returns the status of the Azure Synapse Analytics 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.

To manually update the integration, complete the following steps:

Copy the request example, and replace the values with your own as directed to generate the script. The example provided uses 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.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values to your own, where

Response

The response returns the script for you to run in your environment.

Copy the request example, and replace the values with your own as directed to update the integration settings. The example provided uses JSON format, but the request also accepts YAML. The payload you provide must match the payload sent when .

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

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 , where

The response returns the status of the Azure Synapse Analytics 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.

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.

The response returns the status of the Azure Synapse Analytics 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. .

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

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

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

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.

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.

To manually configure the integration, complete the following steps:

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.

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.

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.

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 .

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.

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

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

(autoBootstrap is true)
(autoBootstrap is false)

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

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.

To manually update the integration, complete the following steps:

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.

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

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.

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.

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.

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.

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.

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-----" } }'

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-----" } }'

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" } } }'

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-----" } }'

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

How-to Guides

Configure an Amazon Redshift Spectrum Integration

Configure an Amazon S3 Integration

Configure a Google BigQuery View-Based Integration

Configure a Starburst (Trino) Integration

Configure a Starburst (Trino) Integration

Requirements

Configure the integration

Generate the configuration snippet

Response

Configure the cluster

Get an integration

Response

Get all integrations

Response

Generate a new Immuta API key

Response

Delete an integration

Response

How-to Guides

Configure a Google BigQuery View-Based Integration

Requirements

Prerequisite

Configure the integration

Response

Get an integration

Response

Get all integrations

Response

Update an integration configuration

Response

Delete an integration

Response

Configure an Amazon Redshift Spectrum Integration

Requirements

Permissions

Configure the integration

Setup the Immuta database

Generate the script

Configure the integration in Immuta

Response

Get an integration

Response

Get all integrations

Response

Update an integration configuration

Generate the updated script

Update the integration in Immuta

Response

Delete an integration

Response

Configure an Amazon S3 Integration

Requirements

Permissions

Set up S3 Access Grants instance and IAM roles

Location IAM role

Authentication IAM role (or user)

Configure the integration in Immuta

Response

Get an integration

Response

Get all integrations

Response

Update an integration configuration

Response

Delete an integration

Response

Configure an Azure Synapse Analytics Integration

Requirements

Configure the integration

Automatic setup

Response

Manual setup

Generate the first script

Generate the second script

Configure the integration in Immuta

Response

Get an integration

Response

Get all integrations