Subscription Policy Access Types

Immuta offers two types of subscription policies to manage read and write access in a single system:

• Read access policies manage who can read data.
• Write access policies manage who can modify data.

Both of these access types can be enforced at any of the restriction levels outlined in the Subscription policies reference guide.

The table below illustrates the access types supported by each integration.

Integration	Read access policies	Write access policies
Snowflake
Databricks Unity Catalog
Databricks Spark		Write access is controlled through workspaces and scratch paths
Starburst (Trino)		:X: Write access can be granted through advanced configuration on the Starburst (Trino) cluster
Redshift		View-based integrations are read-only
Azure Synapse Analytics		View-based integrations are read-only
Amazon S3		Support coming soon
Google BigQuery		View-based integrations are read-only

To create a read or write access policy, see the Author a subscription policy guide.

Policy enforcement

Once a read or write access policy is enforced on an Immuta data source, it translates to the relevant privileges on the table, view, or object in the remote platform. The sections below detail how these access types are enforced for each integration.

Granting Snowflake privileges

The Snowflake integration supports read and write access subscription policies. However, when applying read and write access policies to Snowflake data sources, the privileges granted by Immuta vary depending on the object type. For example, users can register Snowflake views as Immuta data sources and apply read and write policies to them, but when a write policy is applied to a view only the SELECT privilege will take effect in Snowflake, as views are read-only objects.

Users can register any object stored in Snowflake’s information_schema.tables view as an Immuta data source. The table below outlines the Snowflake privileges Immuta issues when read and write policies are applied to various object types in Snowflake. Beyond the privileges listed, Immuta always grants the USAGE privilege on the parent schema and database for any object that access is granted to for a particular user.

Snowflake object	Read policy applied	Write policy applied
Table	SELECT	SELECT, INSERT, UPDATE, DELETE, TRUNCATE
View	SELECT	SELECT, INSERT, UPDATE, DELETE, TRUNCATE ^1^
Materialized view	SELECT	SELECT, INSERT, UPDATE, DELETE, TRUNCATE ^1^
External table	SELECT	SELECT, INSERT, UPDATE, DELETE, TRUNCATE ^1^
Event table	SELECT	SELECT, INSERT, UPDATE, DELETE, TRUNCATE ^1^
Dynamic table	SELECT	No privileges issued by Immuta ^2^
Iceberg table	SELECT	SELECT, INSERT, UPDATE, DELETE, TRUNCATE ^3^
Data object from an incoming Data Share	No privileges issued by Immuta ^4^	No privileges issued by Immuta ^4^

^{1. Snowflake views, materialized views, external tables, and event tables are read-only. Consequently, if a write policy gets applied to a data source of these types, only the SELECT privilege has an effect on users' ability to operate on data.}

^{2. Snowflake dynamic tables are not a supported object type for write policies in Immuta. If a write policy gets applied to a data source of that type, no privileges are issued by Immuta.}

^{3. Iceberg tables using a catalog integration are read-only. Consequently, if a write policy gets applied to a data source of that type, only the SELECT privilege has an effect on users ability to operate on data.}

^{4. Snowflake only supports granting access privileges at the level of a Data Share, but not on individual objects within a Data Share. Therefore, data objects from an incoming Data Share are not supported for subscription policies in Immuta. If a read or write policy gets applied to a data source of that type, no privileges are issued by Immuta.}

Granting Databricks Unity Catalog privileges

The Databricks Unity Catalog integration supports read and write access subscription policies. When users create a subscription policy in Immuta, Immuta uses the Unity Catalog API to issue GRANTS or REVOKES against the catalog, schema, or table in Databricks for every user affected by that subscription policy.

Users can register any object stored in Databricks Unity Catalog’s information_schema.tables view as an Immuta data source. However, when applying read and write access policies to these data sources, the privileges granted by Immuta vary depending on the object type. For example, users can register federated tables as Immuta data sources and apply read and write policies to them, but only a read policy will take effect in Databricks and allow users to SELECT those tables. If a write policy is applied, Immuta will not issue SELECT or MODIFY privileges in Databricks.

The table below outlines the Databricks privileges Immuta issues when read and write policies are applied to various object types in Databricks Unity Catalog. Beyond the privileges listed, Immuta always grants the USAGE privilege on the parent schema and catalog for any object that access is granted to for a particular user.

Databricks Unity Catalog object	Read policy applied	Write policy applied
Table	SELECT	SELECT, MODIFY
View	No privileges issued by Immuta ^1^	No privileges issued by Immuta ^1^
Materialized view	No privileges issued by Immuta ^1^	No privileges issued by Immuta ^1^
External table	SELECT	SELECT, MODIFY
Streaming table	SELECT	SELECT, MODIFY
Federated table	SELECT	No privileges issued by Immuta ^2^
Data object from incoming Delta Share	No privileges issued by Immuta ^3^	No privileges issued by Immuta ^3^

^{1. Databricks Unity Catalog views and materialized views are not supported object types for subscription policies in Immuta. If a read or write policy gets applied to a data source of these types, no privileges are issued by Immuta.}

^{2. Databricks Unity Catalog federated tables are not a supported object type for write policies in Immuta. If a write policy gets applied to a data source of that type, no privileges are issued by Immuta.}

^{3. Data objects from an incoming Delta Share are not supported for subscription policies in Immuta. If a read or write policy gets applied to a data source of that type, no privileges are issued by Immuta.}

Granting Databricks Spark privileges

The Databricks Spark integration supports read access subscription policies. When a read access policy is applied to a data source, Immuta modifies the logical plan that Spark builds when a user queries data to enforce policies that apply that user. If the user is subscribed to the data source, the user is granted SELECT on the object in Databricks. If the user does not have read access to the object, they are denied access.

Granting Starburst (Trino) privileges

The Starburst (Trino) integration supports read access subscription policies. However, administrators can configure the Starburst (Trino) cluster to allow users to write to data using the access-control.properties file using one or both of the following properties:

• immuta.allowed.immuta.datasource.operations: This property governs objects (catalogs, schemas, tables, etc.) that are registered as data sources in Immuta. For these permissions to apply, the user must be subscribed in Immuta and not be an administrator (who gets all permissions).

• immuta.allowed.non.immuta.datasource.operations: This property governs objects (catalogs, schemas, tables, etc.) that are not registered as data sources in Immuta.

By default, Immuta allows READ operations to be authorized on data registered in Immuta, which blocks WRITE operations on these data sources. READ and WRITE operations are permitted by default for data sources that are not registered in Immuta.

Granting Redshift privileges

The Redshift integration supports read access subscription policies. Immuta grants the SELECT Redshift privilege to the PUBLIC role when the integration is configured, which allows all users who meet the conditions of a subscription policy to access the Immuta-managed view. When a data source is created, Immuta creates a corresponding dynamic view of the table with a join to a secure view that contains all Immuta users, their entitlements, their projects, and a list of the tables they have access to. When a read policy is created or updated (or when a user's entitlements change, they switch projects, or when their data source access is approved or revoked), Immuta updates the secure view to grant or revoke users' access to the data source. If a user is granted access to the data source, they can access the view. If a user does not have read access to the view, zero rows are returned when they attempt to query the view.

Granting Azure Synapse Analytics privileges

The Azure Synapse Analytics integration supports read access subscription policies. Immuta grants the SELECT privilege to the PUBLIC role when the integration is configured, which allows all users who meet the conditions of a subscription policy to access the Immuta-managed view. When a read policy is created or removed (or when a user's entitlements change, they switch projects, or when their data source access is approved or revoked), Immuta updates the view that contains the users' entitlements, projects, and a list of tables they have access to grant or revoke their access to the dynamic view. Users' read access is enforced through an access check function in each individual view. If a user is granted access to the data source, they can access the view. If a user does not have read access to the view, they receive an Access denied: you are not subscribed to the data source error when they attempt to query the view.

Granting Google BigQuery privileges

The Google BigQuery integration supports read access subscription policies. In this integration, Immuta creates views that contain all policy logic. Each view has a 1-to-1 relationship with the original table, and read access controls are applied in the view. After data sources are registered, Immuta uses the custom user and role, created before the integration is enabled, to push the Immuta data sources as views into a mirrored dataset of the original table. Immuta manages grants on the created view to ensure only users subscribed to the Immuta data source will see the data.

Granting Amazon S3 privileges

Immuta's Amazon S3 integration allows users to apply read access 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. To query a data source they are subscribed to, users request temporary credentials from their Access Grants instance. These just-in-time access credentials provide access to a prefix, bucket, or object with a permission level of READ in S3. When a user or application requests temporary credentials to access S3 data, the S3 Access Grants instance evaluates the request against the grants Immuta has created for that user. If a matching grant exists, S3 Access Grants assumes the IAM role associated with the location of the matching grant and scopes the permissions of the IAM session to the S3 prefix, bucket, or object specified by the grant and vends these temporary credentials to the requester. If the grant does not exist for the user, they receive an Access denied error.

Write access policy limitations

• Users can only modify existing data when they are granted write access to data; they cannot create new tables or delete tables.
• Write actions are not currently captured in audit logs.