In the Redshift integration, Immuta generates policy-enforced views in your configured Redshift schema for tables registered as Immuta data sources.
Use the /integrations
endpoint to
APPLICATION_ADMIN
Immuta permission
A Redshift cluster with an RA3 node is required for the multi-database integration. You must use a Redshift RA3 instance type because Immuta requires cross-database views, which are only supported in Redshift RA3 instance types. For other instance types, you may configure a single-database integration using one of the Redshift Spectrum options:
Configure the integration with an existing database that contains the external tables. In the steps below, specify an existing database in Redshift as the database
in which Immuta will add the Immuta-managed schemas and views instead of creating a new database.
Create a new database as specified in the steps below, and then re-create all of your external tables in that database.
For automated installations, the credentials provided must be a Superuser or have the ability to create databases and users and modify grants.
Account used to configure or edit the integration must have the following Redshift permissions:
CREATE DATABASE
CREATE USER
REVOKE ALL PRIVILEGES ON DATABASE
GRANT TEMP ON DATABASE
MANAGE GRANTS ON ACCOUNT
You have two options for configuring your Redshift integration:
These privileges will be used to create and configure a new Immuta-managed database within the specified Redshift 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 a Superuser. If you create a new account, it can be deleted after initial setup is complete.
Copy the request example from one of the sections 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 config object description for parameter definitions, value types, and additional configuration options.
The response returns the status of the Redshift integration configuration connection. See the response schema reference for details about the response schema.
To manually configure the integration, complete the following steps:
Copy the request example from one of the tabs below, and replace the values with your own as directed to generate the first script. The examples provided use JSON format, but the request also accepts YAML.
See the config object description for parameter definitions, value types, and additional configuration options.
Response
The response returns the script for you to run in the Redshift initialDatabase.
See the config object description for parameter definitions, value types, and additional configuration options.
Response
The response returns the script for you to run in the database created by the first script.
See the config object description for parameter definitions, value types, and additional configuration options.
The response returns the status of the Redshift integration configuration connection. See the response schema reference for details about the response schema.
Copy the request example.
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to get. Alternatively, you can get a list of all integrations and their IDs with the GET /integrations
endpoint.
The response returns a Redshift integration configuration. See the response schema reference for details about the response schema. An unsuccessful request returns the status code and an error message. See the HTTP status codes and error messages for a list of statuses, error messages, and troubleshooting guidance.
Copy the request example.
Replace the Immuta URL and API key with your own.
The response returns the configuration for all integrations. See the response schema reference for details about the response schema. An unsuccessful request returns the status code and an error message. See the HTTP status codes and error messages for a list of statuses, error messages, and troubleshooting guidance.
You have two options for updating your integration. Follow the steps that match your initial configuration of autoBootstrap:
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 config object description for parameter definitions, value types, and additional configuration options.
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values to your own, where
host is the URL of your Redshift account.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
initialDatabase is the name of an existing database in Redshift that Immuta initially connects to and creates the Immuta-managed database.
okta specifies your username, password, appId, idpHost, and role. See the object description for details about child parameters.
The response returns the status of the Redshift integration configuration connection. See the response schema reference for details about the response schema.
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 config object description for parameter definitions, value types, and additional configuration options.
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
Change the config values to your own, where
host is the URL of your Redshift account.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
initialDatabase is the name of an existing database in Redshift that Immuta initially connects to and creates the Immuta-managed database.
impersonation specifies whether user impersonation is enabled. See the object description for child parameters.
okta specifies your username, password, appId, idpHost, and role. See the object description for details about child parameters.
Run the script returned in the response in your Redshift environment.
Response
The response returns the script for you to run in your Redshift environment.
See the config object description for parameter definitions, value types, and additional configuration options.
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to update.
host is the URL of your Redshift account.
database is the name of a new empty database that the Immuta system user will manage and store metadata in.
initialDatabase is the name of an existing database in Redshift that Immuta initially connects to and creates the Immuta-managed database.
impersonation specifies whether user impersonation is enabled. See the object description for child parameters.
okta specifies your username, password, appId, idpHost, and role. See the object description for details about child parameters.
The response returns the status of the Redshift integration configuration connection. See the response schema reference for details about the response schema.
Copy the request example.
Replace the Immuta URL and API key with your own.
Replace the {id} request parameter with the unique identifier of the integration you want to delete.
If you set
autoBootstrap to true
when enabling the integration, specify the authenticationType and the credentials you used to configure the integration in the payload, as illustrated in the example.
autoBootstrap to false
when enabling the integration, use the script cleanup endpoint (for integrations that were not successfully created) or the delete endpoint (for integrations that were successfully created) to remove Immuta-managed resources from your environment. Then, make the request above without including a payload to remove the integration from Immuta.
The response returns the status of the Redshift integration configuration that has been deleted. See the response schema reference for details about the response schema. An unsuccessful request returns the status code and an error message. See the HTTP status codes and error messages for a list of statuses, error messages, and troubleshooting guidance.