Skip to content

You are viewing documentation for Immuta version 2022.1.

For the latest version, view our documentation for Immuta SaaS or the latest self-hosted version.

cancel

Redshift Overview

Audience: System Administrators, Data Governors, and Data Owners

Content Summary: This page provides an overview of the Redshift integration in Immuta.

For a tutorial detailing how to enable this integration, see the installation guide.

Overview

Redshift is a policy push integration that allows Immuta to apply policies directly in Redshift. This allows data analysts to query Redshift views directly instead of going through a proxy and have per-user policies dynamically applied at query time.

Architecture

The Redshift integration will create views from the tables within the database specified when configured. Then, the user can choose the name for the schema where all the Immuta generated views will reside. Immuta will also create the schemas immuta_system, immuta_functions, and immuta_procedures to contain the tables, views, UDFs, and stored procedures that support the integration.

Integration Type

Immuta supports the Redshift integration as both multi-database and single-database integrations.

Multi-Database Integration

If using a multi-database integration, you must use a Redshift cluster with an RA3 node because Immuta requires cross-database views.

Single-Database Integration

If using a single-database integration, all Redshift cluster types are supported. However, because cross-database queries are not supported in any types other than RA3, Immuta's views must exist in the same database as the raw tables. Consequently, the steps for configuring the integration for Redshift clusters with external tables differ slightly from those that don't have external tables. Allow Immuta to create secure views of your external tables through one of these methods:

Policy Enforcement

SQL statements are used to create all views, including a join to the secure view: immuta_system.user_profile. This secure view is a select from the immuta_system.profile table (which contains all Immuta users and their current groups, attributes, projects, and a list of valid tables they have access to) with a constraint immuta__userid = current_user() to ensure it only contains the profile row for the current user. The immuta_system.user_profile view is readable by all users, but will only display the data that corresponds to the user executing the query.

The Redshift integration uses webhooks to keep views up-to-date with Immuta data sources. When a data source or policy is created, updated, or disabled, a webhook will be called that will create, modify, or delete the dynamic view. The immuta_system.profile table is updated through webhooks when a user's groups or attributes change, they switch projects, they acknowledge a purpose, or when their data source access is approved or revoked. The profile table can only be read and updated by the Immuta system account.

Data Flow

  1. An Immuta Application Administrator configures the Redshift integration and registers Redshift warehouse and databases with Immuta.
  2. Immuta creates a database inside the configured Redshift ecosystem that contains Immuta policy definitions and user entitlements.
  3. A Data Owner registers Redshift tables in Immuta as data sources.
  4. A Data Owner, Data Governor, or Administrator creates or changes a policy or user in Immuta.
  5. Data source metadata, tags, user metadata, and policy definitions are stored in Immuta's Metadata Database.
  6. The Immuta Web Service calls a stored procedure that modifies the user entitlements or policies.
  7. A Redshift user who is subscribed to the data source in Immuta queries the corresponding table directly in Redshift through the immuta database and sees policy-enforced data.

Redshift Diagram