# Subscription Policy Access Types {% hint style="info" %} **Private preview**: Write policies are available to select accounts. Contact your Immuta representative to enable this feature. {% endhint %} Immuta offers two [subscription policy access types](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/reference-guides/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](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/reference-guides/subscription-policies). The table below illustrates the access types supported by each integration. | Integration | Read access policies | Write access policies | | :--------------------------------------------------------------------------------------------------------------------: | :------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | [Amazon Redshift](#granting-amazon-redshift-privileges) | :white\_check\_mark: | :white\_check\_mark: | | [Amazon Redshift Spectrum](#granting-amazon-redshift-spectrum-privileges) | :white\_check\_mark: | :x: View-based integrations are read-only | | [Amazon S3](#granting-amazon-s3-privileges) | :white\_check\_mark: | :white\_check\_mark: | | [AWS Lake Formation](#granting-aws-lake-formation-privileges) | :white\_check\_mark: | :white\_check\_mark: | | [Azure Synapse Analytics](#granting-azure-synapse-analytics-privileges) | :white\_check\_mark: | :x: View-based integrations are read-only | | [Databricks Lakebase](https://documentation.immuta.com/saas/configuration/integrations/databricks/databricks-lakebase) | :white\_check\_mark: | :white\_check\_mark: | | [Databricks Spark](#granting-databricks-spark-privileges) | :white\_check\_mark: | :x: Write access is controlled through [workspaces](https://documentation.immuta.com/saas/govern/projects-and-purpose-based-access-control/write-index/reference-guides/project-workspaces#databricks-project-workspace-workflow) and [scratch paths](https://documentation.immuta.com/saas/configuration/integrations/databricks/databricks-spark/reference-guides/databricks/configuration#immuta_spark_databricks_scratch_paths) | | [Databricks Unity Catalog](#granting-databricks-unity-catalog-privileges) | :white\_check\_mark: | :white\_check\_mark: | | [Google BigQuery](#granting-google-bigquery-privileges) | :white\_check\_mark: | :x: View-based integrations are read-only | | [PostgreSQL](#granting-postgresql-privileges) | :white\_check\_mark: | :white\_check\_mark: | | [Snowflake](#granting-snowflake-privileges) | :white\_check\_mark: | :white\_check\_mark: | | [Starburst (Trino)](#granting-starburst-trino-privileges) | :white\_check\_mark: | :white\_check\_mark: | | [Teradata](#granting-teradata-privileges) | :white\_check\_mark: | :x: View-based integrations are read-only | To create a read or write access policy, see the [Author a subscription policy guide](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/subscription-policy-tutorial). ## 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 Amazon Redshift privileges The Amazon Redshift integration supports read and write access subscription policies. Once a subscription policy is applied to Amazon Redshift data sources, Immuta issues Amazon Redshift privileges to users who are subscribed to that data source. However, the privilege issued depends on the object type. The table below outlines the Amazon Redshift privileges Immuta issues when read and write policies are applied to various object types. | Amazon Redshift object type | Read policy applied | Write policy applied | | --------------------------- | ------------------- | ---------------------------------------- | | Table | SELECT | SELECT, INSERT, UPDATE, DELETE, TRUNCATE | | View | SELECT | SELECT[^1] | | Datashare | SELECT | SELECT[^2] | ### Granting Amazon Redshift Spectrum privileges The Amazon Redshift Spectrum 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 Amazon S3 privileges The Amazon S3 integration supports read and write access subscription policies. Users can apply read and write access policies to data in S3 to restrict what prefixes, buckets, or objects users can access or modify. 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` or `READWRITE`](#s3-access-grants-read-and-readwrite-access-levels) 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. #### S3 Access Grants `READ` and `READWRITE` access levels Immuta read policies translate to the `READ` access level in S3 Access Grants and Immuta write policies translate to the `READWRITE` access level. The table below outlines the Amazon S3 actions granted on an S3 data source when users meet the restrictions specified in an Immuta read or write access subscription policy that is applied to the data source. See the [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) for more details about grants, access levels, and actions. | Immuta policy | S3 Access Grants access level | Amazon S3 action | | ------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Read | `READ` | | | Write | `READWRITE` | | ### Granting AWS Lake Formation privileges The AWS Lake Formation integration supports read and write access subscription policies. Users can connect tables or views registered in their Glue Data Catalog to Immuta. Once a subscription policy is applied to those data sources, Immuta will orchestrate Lake Formation access controls on that data. The table below outlines the Lake Formation permissions Immuta issues when read and write policies are applied to various object types in the Glue Data Catalog.
Glue Data Catalog object typeRead policy appliedWrite policy applied
TableSELECT, DESCRIBESELECT, DESCRIBE, INSERT, DELETE
ViewSELECT, DESCRIBESELECT, DESCRIBE
### 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 Databricks Lakebase privileges Immuta grants access to Databricks Lakebase through PostgreSQL privileges. See the [granting PostgreSQL privileges](#granting-postgresql-privileges) section for reference. ### 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 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` and `information_schema.volumes` views 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 foreign 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 typeRead policy appliedWrite policy applied
Table (MANAGED)SELECTSELECT, MODIFY
View (VIEW)SELECTSELECT
Materialized view (MATERIALIZED_VIEW)SELECTSELECT
Streaming table (STREAMING_TABLE)SELECTSELECT
External table (EXTERNAL)SELECTSELECT, MODIFY
Foreign table (FOREIGN)SELECT❌ No privileges issued by Immuta
Volumes (EXTERNAL and MANAGED)READ VOLUMEWRITE VOLUME
ModelsEXECUTEMANAGE
FunctionsEXECUTEMANAGE
Data object from incoming Delta ShareSELECTSELECT
### 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 PostgreSQL privileges The PostgreSQL integration supports read and write access subscription policies. Once a subscription policy is applied to PostgreSQL data sources, Immuta issues PostgreSQL privileges to users who are subscribed to that data source. However, the PostgreSQL privilege issued depends on the object type.
PostgreSQL object typeRead policy appliedWrite policy applied
Ordinary table (r)SELECTSELECT, INSERT, UPDATE, DELETE, TRUNCATE
View (v)SELECTSELECT, INSERT, UPDATE, DELETE, TRUNCATE
Materialized view (m)SELECTSELECT, INSERT, UPDATE, DELETE, TRUNCATE
Partitioned table (p)SELECTSELECT, INSERT, UPDATE, DELETE, TRUNCATE
### 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 type | Read policy applied | Write policy applied | | :-------------------------------------: | :------------------------------------------------------------: | :------------------------------------------------------------------: | | Table (`BASE TABLE`) | SELECT | SELECT, INSERT, UPDATE, DELETE, TRUNCATE | | View (`VIEW`) | SELECT | [SELECT, INSERT, UPDATE, DELETE, TRUNCATE](#user-content-fn-13)[^13] | | Materialized view (`MATERIALIZED VIEW`) | SELECT | [SELECT, INSERT, UPDATE, DELETE, TRUNCATE](#user-content-fn-13)[^13] | | External table (`EXTERNAL TABLE`) | SELECT | [SELECT, INSERT, UPDATE, DELETE, TRUNCATE](#user-content-fn-13)[^13] | | Event table (`EVENT TABLE`) | SELECT | [SELECT, INSERT, UPDATE, DELETE, TRUNCATE](#user-content-fn-13)[^13] | | Iceberg table (`IS_ICEBERG=YES`) | SELECT | [SELECT, INSERT, UPDATE, DELETE, TRUNCATE](#user-content-fn-14)[^14] | | Dynamic table (`IS_DYNAMIC=YES`) | SELECT | :x: [No privileges issued by Immuta](#user-content-fn-15)[^15] | | Data object from an incoming Data Share | :x: [No privileges issued by Immuta](#user-content-fn-16)[^16] | :x: [No privileges issued by Immuta](#user-content-fn-16)[^16] | ### Granting Starburst (Trino) privileges The Starburst (Trino) integration supports read and write access subscription policies. In the Starburst (Trino) integration's default configuration, the following access values grant read and write access to Starburst (Trino) data when a user is granted access through a subscription policy: * **`READ`**: When a user is granted read access to a data source, they can `SELECT` on tables or views and `SHOW` on tables, views, or columns in Starburst (Trino). This setting in enabled by default when you configure the Starburst (Trino) integration. * **`WRITE`**: In its default setting, the Starburst (Trino) integration's write access value controls the authorization of SQL operations that perform data modification (such as `INSERT`, `UPDATE`, `DELETE`, `MERGE`, and `TRUNCATE`). When users are granted write access to a data source through a subscription policy, they can `INSERT`, `UPDATE`, `DELETE`, `MERGE`, and `TRUNCATE` on tables and `REFRESH` on materialized views. This setting is enabled by default when you configure the Starburst (Trino) integration. Administrators can customize write access configuration to grant additional Starburst (Trino) table modification privileges. See the [Custom configuration section](#custom-configuration) below for an overview and example configurations. #### Custom configuration Because Starburst (Trino) can govern certain table modification operations (like `ALTER`) separately from data modification operations (like `INSERT`), Immuta allows users to specify what modification operations are permitted on data in Starburst (Trino). Administrators can allow table modification operations (such as `ALTER` and `DROP` tables) to be authorized as write operations through advanced configuration in the Immuta web service or Starburst (Trino) cluster with the following access values: * **`OWN`**: When mapped via advanced configuration to Immuta write policies, users who are granted write access to Starburst (Trino) data can `ALTER` and `DROP` tables and `SET` comments and properties on a data source. * **`CREATE`**: When this privilege is granted on Starburst (Trino) data, an Immuta user can create catalogs, schemas, tables, or views on a Starburst (Trino) cluster. `CREATE` is a Starburst (Trino) privilege that is not controlled by Immuta policies, and this property can only be set in the `access-control.properties` file on the Starburst (Trino) cluster. Administrators can customize table and data modification settings in one or both of the following places; however, the `access-control.properties` overrides the settings configured in the Immuta web service: * **Immuta web service**: Configuring write policies in the Immuta web service allows all Starburst (Trino) clusters targeting that Immuta tenant to receive the same write policy configuration for Immuta data sources. This configuration only affects tables or views registered as Immuta data sources. Use the option below to control how unregistered data is affected. * **Starburst (Trino) cluster**: Configuring write policies using the [`access-control.properties`](https://documentation.immuta.com/saas/configuration/integrations/starburst-trino/how-to-guides/configure#id-2-configure-the-immuta-system-access-control-plugin-in-starburst) file on a Starburst ([Trino](https://documentation.immuta.com/saas/configuration/integrations/starburst-trino/how-to-guides/configure#id-2-configure-the-immuta-system-access-control-plugin-in-trino)) cluster allows access to be broadly customized for Immuta users on that cluster. This configuration file takes precedence over write policies passed from the Immuta web service. Use this option if all Immuta users should have the same level of access to data regardless of the configuration in the Immuta web service. **Immuta web service access grants mapping** Customizing read and write access in the Immuta web service affects operations on all Starburst (Trino) data registered as Immuta data sources in that Immuta tenant. This configuration method should be used when all Starburst (Trino) data source operations should be affected identically across Starburst (Trino) clusters connected to the Immuta web service. Example configurations are provided below. Contact your Immuta representative to customize the mapping of read or write access policies for your Immuta tenant. {% tabs %} {% tab title="Default configuration" %} **Default configuration** The default setting shown below maps `WRITE` to `READ` and `WRITE` permissions and maps `READ` to `READ`. Both the `READ` and `WRITE` permission should always include `READ`. In this example, if a user is granted write access to a data source through a subscription policy, that user can perform data modification operations (`INSERT`, `UPDATE`, `MERGE`, etc.) on the data. ```yaml accessGrantMapping: WRITE: ['READ', 'WRITE'] READ: ['READ'] ``` {% endtab %} {% tab title="Custom configuration" %} **Custom configuration** The following configuration example maps `WRITE` to `READ`, `WRITE`, and `OWN` permissions and maps `READ` to `READ`. Both `READ` and `WRITE` permissions should always include `READ`. In this example, if a user gets write access to a data source through a subscription policy, that user can perform both data (`INSERT`, `UPDATE`, `MERGE`, etc.) and table (`ALTER`, `DROP`, etc.) modification operations on the data. ```yaml accessGrantMapping: WRITE: ['READ', 'WRITE', 'OWN'] READ: ['READ'] ``` {% endtab %} {% endtabs %} **Starburst (Trino) cluster access grants mapping** The Starburst (Trino) integration can also be configured to allow read and write policies to apply to any data source (registered or unregistered in Immuta) on a specific Starburst (Trino) cluster. {% tabs %} {% tab title="Default configuration" %} The default setting shown below maps `WRITE` to `READ` and `WRITE` permissions and maps `READ` to `READ`. Both the `READ` and `WRITE` permission should always include `READ`. In this example, if a user is granted write access to a data source through a subscription policy, that user can perform data modification operations (`INSERT`, `UPDATE`, `MERGE`, etc.) on the data. ```yaml accessGrantMapping: WRITE: ['READ', 'WRITE'] READ: ['READ'] ``` {% endtab %} {% tab title="Custom configuration" %} The following configuration example maps `WRITE` to `READ`, `WRITE`, and `OWN` permissions and maps `READ` to `READ`. Both `READ` and `WRITE` permissions should always include `READ`. In this example, if a user gets write access to a data source through a subscription policy, that user can perform both data (`INSERT`, `UPDATE`, `MERGE`, etc.) and table (`ALTER`, `DROP`, etc.) modification operations on the data. ```yaml accessGrantMapping: WRITE: ['READ', 'WRITE', 'OWN'] READ: ['READ'] ``` {% endtab %} {% endtabs %} Two properties customize the behavior of read or write access for all Immuta users on that Starburst cluster: * **`immuta.allowed.immuta.datasource.operations`**: This property governs objects (catalogs, schemas, tables, etc.) that are registered as data sources in Immuta. These permissions apply to all querying users except for administrators defined in `immuta.user.admin` (who get 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. *This is the only property that allows the `CREATE` permission, since `CREATE` is enforced on new objects that do not exist in Starburst or Immuta yet (such as a new table being created with `CREATE TABLE`).* The default configuration and an example of a custom configuration are provided below. See the [Customize read and write access policies in Starburst page](https://documentation.immuta.com/saas/configuration/integrations/starburst-trino/how-to-guides/write-access-mapping#starburst-cluster-configuration) for guidance on configuring these properties in your Starburst cluster. {% tabs %} {% tab title="Default configuration" %} **Default configuration** By default, Immuta allows `READ` and `WRITE` operations to be authorized on data registered in Immuta, while all operations are permitted for data sources that are not registered in Immuta. ```bash immuta.allowed.immuta.datasource.operations=READ,WRITE immuta.allowed.non.immuta.datasource.operations=READ,WRITE,CREATE,OWN ``` {% endtab %} {% tab title="Custom configuration" %} **Custom configuration** In the example below, the configuration allows `READ`, `WRITE`, and `OWN` operations to be authorized on data sources registered in Immuta and all operations are permitted on data that is not registered in Immuta. If a user gets write access to data registered in Immuta through a subscription policy, that user can perform both data (`INSERT`, `UPDATE`, `MERGE`, etc.) and table (`ALTER`, `DROP`, etc.) modification operations on the data. ```bash immuta.allowed.immuta.datasource.operations=READ,WRITE,OWN immuta.allowed.non.immuta.datasource.operations=READ,WRITE,CREATE,OWN ``` {% endtab %} {% endtabs %} ### Granting Teradata privileges The Teradata integration supports read access subscription policies. Users can connect views registered in Teradata to Immuta. Once a subscription policy is applied to those data sources, Immuta issues the `SELECT` Teradata privilege to users who are subscribed to that data source. ## Write access policy limitations * With the exception of the Starburst integration, 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 and governance reports. [^1]: Views are not a supported object type for the `INSERT`, `UPDATE`, `DELETE`, or `TRUNCATE` permission. If a write policy gets applied to a data source of that type, only the `SELECT` permission is issued by Immuta. [^2]: Datashares are not a supported object type for the `INSERT`, `UPDATE`, `DELETE`, or `TRUNCATE` permission. If a write policy gets applied to a data source of that type, only the `SELECT` permission is issued by Immuta. [^3]: Immuta only governs Glue Data Catalog tables accessed using Athena, EMR Spark, or Redshift Spectrum. [^4]: Immuta only governs Glue Data Catalog views accessed using Athena, EMR Spark, or Redshift Spectrum. [^5]: Views are not a supported object type for the `INSERT` or `DELETE` permission. If a write policy gets applied to a data source of that type, only the `SELECT` and `DESCRIBE` permissions are issued by Immuta. [^6]: Databricks Unity Catalog views are not a supported object type for the `MODIFY` privilege. If a write policy gets applied to a data source of that type, only the `SELECT` privilege gets issued by Immuta. [^7]: Databricks Unity Catalog materialized views are not a supported object type for the `MODIFY` privilege. If a write policy gets applied to a data source of that type, only the `SELECT` privilege gets issued by Immuta. [^8]: Databricks Unity Catalog streaming tables are not a supported object type for the `MODIFY` privilege. If a write policy gets applied to a data source of that type, only the `SELECT` privilege gets issued by Immuta. [^9]: Databricks Unity Catalog foreign 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. [^10]: This object type is only supported if you are using [connections](https://documentation.immuta.com/saas/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/connections-overview) to set up the integration and register data. [^11]: Data objects from an incoming Delta Share are not a supported object type for the `MODIFY` privilege. If a write policy gets applied to a data source of that type, only the `SELECT` privilege gets issued by Immuta. [^12]: PosgreSQL views and materialized views 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. [^13]: 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. [^14]: 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. [^15]: 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. [^16]: 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.