Redshift Pre-Configuration Details
This page describes the Redshift integration, configuration options, and features. For a tutorial to enable this integration, see the installation guide.
Feature Availability
❌
❌
✅
❌
✅
Prerequisite
For automated installations, the credentials provided must be a Superuser or have the ability to create databases and users and modify grants.
Supported Features
Redshift Serverless.
Redshift Spectrum For configuration and data source registration instructions, see the configuration page.
Authentication Methods
The Redshift integration supports the following authentication methods to configure the integration and create data sources:
Username and Password: Users can authenticate with their Redshift username and password.
AWS Access Key: Users can authenticate with an AWS access key.
Okta: Users can authenticate with their Okta credentials when installing the integration with the manual configuration.
Deprecation notice
Support for Okta authentication has been deprecated.
Tag Ingestion
Immuta cannot ingest tags from Redshift, but you can connect any of these supported external catalogs to work with your integration.
User Impersonation
Required Redshift privileges
Setup User:
OWNERSHIP ON GROUP IMMUTA_IMPERSONATOR_ROLECREATE GROUP
Immuta System Account:
GRANT EXECUTE ON PROCEDURE grant_impersonationGRANT EXECUTE ON PROCEDURE revoke_impersonation
Impersonation allows users to query data as another Immuta user in Redshift. To enable user impersonation, see the User Impersonation page.
Multiple Integrations
Users can enable multiple Redshift integrations with a single Immuta tenant.
Redshift Limitations
The host of the data source must match the host of the native connection for the native view to be created.
When using multiple Redshift integrations, a user has to have the same user account across all hosts.
Registering Redshift datashares as Immuta data sources is unsupported.
Case sensitivity of database, table, and column identifiers is not supported. The
enable_case_sensitive_identifierparameter must be set tofalse(default setting) for your Redshift cluster to configure the integration and register data sources.
Python UDF Specific Limitations
For most policy types in Redshift, Immuta uses SQL clauses to implement enforcement logic; however Immuta uses Python UDFs in the Redshift integration to implement the following masking policies:
Masking using a regular expression
Reversible masking
Format-preserving masking
Randomized response
The number of Python UDFs that can run concurrently per Redshift cluster is limited to one-fourth of the total concurrency level for the cluster. For example, if the Redshift cluster is configured with a concurrency of 15, a maximum of three Python UDFs can run concurrently. After the limit is reached, Python UDFs are queued for execution within workload management queues.
The SVL_QUERY_QUEUE_INFO view in Redshift, which is visible to a Redshift superuser, summarizes details for queries that spent time in a workload management (WLM) query queue. Queries must be completed in order to appear as results in the SVL_QUERY_QUEUE_INFO view.
If you find that queries on Immuta-built views are spending time in the workload management (WLM) query queue, you should either edit your Redshift cluster configuration to increase concurrency, or use fewer of the masking policies which leverage Python UDFs. For more information on increasing concurrency, see the Redshift docs on implementing workload management.
Last updated