Skip to content

You are viewing documentation for Immuta version 2021.4.

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

cancel

Trino Access Pattern

Audience: System Administrators

Content Summary: This page describes the Native Trino access pattern (previously PrestoSQL), through which Immuta applies policies directly in Trino.

See the Enable Native Trino page for a tutorial on enabling Native Trino through the App Settings page.

Overview

The native Trino access pattern applies policies directly in Trino without users going through the Immuta Query Engine. This means users can use their existing Trino tooling (querying, reporting, etc.) and have per-user policies dynamically applied at query time.

This feature works with an Immuta Trino connector that is fully dynamic. It generates the list of available schemas and views at query time based on each individual user. After a user executes a query against an Immuta view, the connector dynamically generates a view definition to provide to the Trino execution engine. This definition will then connect the engine to backing catalogs and retrieve the data with the appropriate policy enforcement.

Architecture

In addition to configuring this access pattern on the App Settings page, Administrators will also need to install the Immuta Trino plugin on all Trino nodes within their cluster.

Once the plugin has been pushed out to all nodes, they will also need to create an Immuta catalog, which will be managed by a custom Immuta Trino connector that will generate the list of available schemas and views at query time based on the user making the request. When a user executes a query against one of the Immuta views, the connector dynamically generates the view definition and provides that to the Trino execution engine, which then connects to the backing catalogs and retrieves the data with appropriate policy enforcement.

Policy Enforcement

Policies are enforced directly into the dynamically generated views. The views will include a JOIN to a fact table containing the querying users' groups, authorities, purposes, and current projects. This user profile information is not a static row in a table but rather a dynamic dummy clause to be generated at query time.

Limitations

  • Immuta will not be able to accurately represent certain policies in Trino, and data sources with these policies applied will not appear in the Immuta catalog. This limitation includes data sources

    • that have a differential privacy policy applied,
    • with an external policy handler, or
    • that are using the Advanced Rules DSL.

  • Certain interpolation functions can block the creation of a native view, specifically @interpolatedComparison() and @iam.

  • Trino supports an optional anonymous (no authentication) access, which is not supported through Immuta because we have to tie the Trino user account to the Immuta user account to correctly apply policies. If your organization allows anonymous access, you will not be able to leverage the native Immuta integration.

  • Native Trino in Immuta is only compatible with Trino (previously named PrestoSQL). PrestoDB is not supported.