Subscription policies manage table-level access to data. The how-to and reference guides in this section detail how to implement subscription policies to meet your compliance requirements and describe the types of subscription policies available.

How-to guides

• Subscription policy: Author a subscription policy to manage access to data sources.

• ABAC subscription policy: Author a subscription policy that uses attribute-based access controls to automate data access decisions.

• Advanced DSL builder: Author a subscription policy using the advanced special functions.

• Restricted subscription policy: As a data owner, author a single subscription policy that can apply to multiple data sources you own.

• Clone, activate, or stage a global policy: Clone, activate, or stage a global policy.

Reference guides

• Subscription policies: This reference guide describes the design and behavior of Immuta subscriptions policies.

• Subscription policy access types: This reference guide describes read and write access policies and how they translate to privileges in the remote data platform.

• Advanced use of special functions: This reference guide defines the advanced functions available when building subscription policies.

This guide demonstrates how to build attribute-based access control (ABAC) subscription policies using the policy builder in the Immuta UI. To build more complex policies than the builder allows, follow the Advanced rules DSL policy guide.

1. Determine your policy scope:

   • Global policy: Click the Policies page icon in the left sidebar and select the Subscription Policies tab. Click Add Subscription Policy and complete the Enter Name field.

   • Local policy: Navigate to a specific data source and click the Policies tab. Click Add Subscription Policy and select New Local Subscription Policy.

2. Select Allow users with specific groups/attributes.

3. Choose the condition that will drive the policy: when user is a member of a group or possesses attribute.

4. Use the subsequent dropdown to choose the group or attribute for your condition. You can add more than one condition by selecting + Add Another Condition. The dropdown menu in the subscription policy builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.

5. Check the Require Manual Subscription checkbox to turn off automatic subscription. Enabling this feature will require users to manually subscribe to the data source if they meet the policy.

6. If you would like to make your data source visible in the list of all data sources in the UI to all users, click the Allow Data Source Discovery checkbox. Otherwise, this data source will not be discoverable by users who do not meet the criteria established in the policy.

7. If you would like users to have the ability to request approval to the data source, even if they do not have the required attributes or traits, check the Request Approval to Access checkbox. This will require an approver with permissions to be set.

8. For global policies: Select how you want Immuta to merge multiple global subscription policies that apply to a single data source.

   • Always Required: Users must meet all the conditions outlined in each policy to get access (i.e., the conditions of the policies are combined with AND).

   • Share Responsibility: Users need to meet the condition of at least one policy that applies (i.e., the conditions of the policies are combined with OR).

   Note: To make this option selected by default, see the app settings page.

9. For global policies: Click the dropdown menu beneath Where should this policy be applied and select When selected by data owners, On all data sources, or On data sources. If you selected On data sources, finish the condition in one of the following ways:

   • tagged: Select this option and then search for tags in the subsequent dropdown menu.

   • with columns tagged: Select this option and then search for tags in the subsequent dropdown menu.

   • with column names spelled like: Select this option, and then enter a regex and choose a modifier in the subsequent fields.

   • in server: Select this option and then choose a server from the subsequent dropdown menu to apply the policy to data sources that share this connection string.

   • created between: Select this option and then choose a start date and an end date in the subsequent dropdown menus.

10. Click Create Policy. If creating a global policy, you then need to click Activate Policy or Stage Policy.

Additional global ABAC subscription policies

When you have multiple global ABAC subscription policies to enforce, create separate global ABAC subscription policies, and then Immuta will use boolean logic to merge all the relevant policies on the tables they map to.

Write access policy requirements

• At least one of the following permissions is required to manage write policies:

  • CREATE_DATA_SOURCE Immuta permission (to create local write policies)

  • GOVERNANCE Immuta permission (to create local or global write policies)

  • MANAGE_POLICIES domain permission (to create global write policies)

• Databricks Unity Catalog, Snowflake, or Starburst (Trino) integration

• Snowflake table grants enabled (for Snowflake integrations)

Create a policy

1. Determine your policy scope:

   • Global policy: Click the Policies page icon in the left sidebar and select the Subscription Policies tab. Click Add Subscription Policy and complete the Enter Name field.

   • Local policy: Navigate to a specific data source and click the Policies tab. Click Add Subscription Policy and select New Local Subscription Policy.

2. Select the access type:

   • Read Access: Control who can view the data source.

   • Write Access: Control who can view and modify data in the data source.

3. Select the level of access restriction you would like to apply:

   • Allow anyone: Check the Require Manual Subscription checkbox to turn off automatic subscription. Enabling this feature will require users to manually subscribe to the data source if they meet the policy.

   • Allow anyone who asks (and is approved):

     1. Click Anyone or An individual selected by user from the first dropdown menu in the subscription policy builder.

        Note: If you choose An individual selected by user, when users request access to a data source they will be prompted to identify an approver with the permission specified in the policy and how they plan to use the data.

     2. Select the Owner (of the data source), USER_ADMIN, GOVERNANCE, or AUDIT permission from the subsequent dropdown menu.

        Note: You can add more than one approving party by selecting + Add Another Approver.

   • Allow users with specific groups/attributes: See the ABAC subscription policy guide for instructions.

   • Allow individually selected users

4. For global policies: From the Where should this policy be applied dropdown menu, select When selected by data owners, On all data sources, or On data sources. If you selected On data sources, finish the condition in one of the following ways:

   • tagged: Select this option and then search for tags in the subsequent dropdown menu.

   • with columns tagged: Select this option and then search for tags in the subsequent dropdown menu.

   • with column names spelled like: Select this option, and then enter a regex and choose a modifier in the subsequent fields.

   • in server: Select this option and then choose a server from the subsequent dropdown menu to apply the policy to data sources that share this connection string.

   • created between: Select this option and then choose a start date and an end date in the subsequent dropdown menus.

5. Click Create Policy. If creating a global policy, you then need to click Activate Policy or Stage Policy.

Manually grant access

Read and write access can also be granted manually by a data owner. See the Manage data source members guide for details.

Additional global ABAC subscription policies

When you have multiple global ABAC subscription policies to enforce, create separate global ABAC subscription policies, and then Immuta will use boolean logic to merge all the relevant policies on the tables they map to.

Subscription policies manage access to tables; they can be defined one of four ways:

• Anyone: Users will automatically be granted access (least restricted).

• Anyone who asks (and is approved): Users will need to request access and be granted permission by the configured approvers (moderately restricted).

• Users with specific groups or attributes: Only users with the specified groups/attributes will be able to see the data source and subscribe (moderately restricted). This restriction type is referred to as an attribute-based access control (ABAC) global subscription policy throughout this page.

• Individual users you select: The data source will not appear in search results; data owners must manually add/remove users (most restricted).

Immuta almost always recommends the ABAC global subscription policies, as described in our two Secure policy use cases:

1. Automate data access control decisions

2. Compliantly open more sensitive data for ML and analytics

See Author a global subscription policy for a tutorial.

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 view data from the specified data sources.

• Write access policies manage who can view and modify data in the specified data sources.

See the Subscription policy access types guide for details.

ABAC global subscription policies

When building an ABAC global subscription policy, the users that match the condition of the policy will automatically be subscribed to the data source by default without taking any action once the policy is activated.

Should user attributes or groups change, that will immediately impact their subscription status if the change results in them either gaining or losing subscription access to table in question. That is the power in these types of policies. You are future proofing the need to alter policies and instead simply need to represent the correct metadata on your users and the policies will react.

Also, by default, user access is reflected appropriately in the Immuta user interface. If a user does not have access to a particular table, that data source will not be visible to them.

The above default behavior can be altered using the below settings in the subscription policy builder:

• Allow Data Source Discovery Configures visibility so that data sources that the user cannot subscribe to are still discoverable in the Immuta.

• Require Manual Subscription In this case, rather than automatically subscribing users to the table, they must click the subscribe button in Immuta to subscribe to the table. This can be valuable if data consumers don't want to have thousands of tables they could access listed in their data platform, only the ones they care about.

• Request Approval to Access Selecting this option allows users to request access to a data source and be manually approved by a specified user, even if the requesting user does not meet the group or attribute conditions in the policy. This setting requires Allow Data Source Discovery to be selected as well; otherwise, they could never discover the data source to request the override. See Global subscription policy merging for a tutorial.

For instructions on creating ABAC subscription policies, see the ABAC subscription policy guide.

Merging ABAC global subscription policies

In some cases, multiple ABAC global policies may apply to a single data source and can allow delegation of policy to many different policy builders. Rather than allowing the two policies to conflict, Immuta combines the conditions of the subscription policies.

Combining of global subscription policies only occurs with ABAC subscription policies. See the next section for how to deal with non-ABAC subscription policy conflicts.

In the ABAC subscription policy builder, the below option determines how to merge subscription policies:

• Always Required: Users must meet all the conditions outlined in each policy to get access (i.e., the conditions of the policies are combined with AND).

• Share Responsibility: Users need to meet the condition of at least one policy that applies (i.e., the conditions of the policies are combined with OR).

Consider the following global subscription policies potentially created by completely different users:

Policy 1: (Always Required)

Allow users to subscribe to the data source when user is a member of group HR; otherwise, allow users to subscribe when approved by an Owner of the data source.

Policy 2: (Shared Responsibility)

Allow users to subscribe to the data source when user is a member of group Analytics; otherwise, allow users to subscribe when approved by anyone with permission Governance.

Policy 3: (Shared Responsibility)

Allow users to subscribe to the data source when user has attribute Office Location Ohio; otherwise, allow users to subscribe when approved by anyone with permission Audit.

If a data source exists where all of these policies apply, the subscription policies are combined, which will result in a policy like this:

Combined policy:

Allow users to subscribe to the data source when user (@isInGroups('HR')) AND ((@isInGroups('Analytics')) OR (@hasAttribute('Office Location', 'Ohio')))

Otherwise

Allow users to subscribe when approved by ( anyone with permission Owner (of this data source) )

AND

( ( anyone with permission GOVERNANCE ) OR ( anyone with permission AUDIT ) )

Note that all the policies which have Always Required must have a manual override (approve by) selected for there to be any approved by in the final merged policy.

Once enabled on a data source, combined global subscription policies can be edited and disabled by data owners.

Find a real example of the power behind merging subscription policies in the Automate data access control decisions use case.

Managing non-ABAC subscription policy conflicts

If straying outside ABAC subscription policies, it is possible multiple global subscription policies created may apply to a single data source and not merge.

More specifically, if two or more global subscription policies of the restriction levels listed below apply to the same table (even if an ABAC subscription policy is also present) source they will conflict:

• Anyone

• Anyone who asks (and is approved)

• Individual users you select

When such conflicts occur, data owners can manually choose which policy will apply. To do this the data owner must

1. Disable the applied global subscription policy in the policies tab on a data source.

2. Provide a reason the global policy should be disabled.

3. Select which conflicting global subscription policy they want to apply.

ABAC global subscription policies using advanced domain specific language

Users can create more complex policies using functions and variables in the advanced DSL policy builder than the subscription policy builder allows.

After an application admin has enabled enhanced subscription policy variables, data governors and owners can create global subscription policies using all the functions and variables outlined below.

The above table provides some basic guidance, for more information refer to the Advanced use of special functions.

See the Advanced DSL tutorial for details on how to build a policy that includes advanced DSL.

Default subscription policy

By default, Immuta does not apply a subscription policy on registered data (unless an existing global policy applies to it).

You can disable this behavior, but there are very few scenarios in which it is recommended to disable. It is best to instead have subscription policies active on standby that will be applied as you add tags to your data sources that drive those subscription policies. This is because global policies that match registered data sources will apply to data sources, no matter which subscription policy is enabled by default.

Default subscription policy options

There are two settings available as the default subscription policy: none or allow individually selected users.

• None: The default. If this option is selected as the default subscription policy, a data source will have no subscription policy applied to it if

  • it is a new data source and no global policy matches it.

  • a data owner or governor removes an existing global subscription policy from the data source.

  Once a global subscription policy matches or a data owner applies a local subscription policy to a data source, that policy will restrict users’ access to the table.

• Allow individually selected users: If this option is selected, data owners have to manually add users as subscribers to the data source in Immuta for those users to query the underlying table.

Changing the default subscription policy setting only affects new data sources; existing data sources (and those in the process of being registered when the setting is changed) are unaffected. For example, if an Immuta data source’s subscription policy restricts access to members of the Marketing group before the feature is enabled, that existing subscription policy will still apply to that table in the underlying data platform; only users who are members of the Marketing group will be able to access that data.

For instructions on changing the default subscription policy setting, see the manage default subscription policy page.

Managing data policies when there is no subscription policy

Even if there is no subscription policy on a table, data owners and governors can manage data policies on data sources without affecting users’ access to the registered data sources. This can be powerful to manage table access outside of Immuta but want to manage data policies in Immuta.

Managing data source members

If no subscription policy is applied to a data source, users can only subscribe as data source owners; they cannot be added as regular subscribers. To add regular subscribers, a data owner or governor must apply a subscription policy to the data source.

Immuta offers two types of 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 .

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

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

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.

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 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.

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 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.

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.

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.

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.

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. 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. 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).

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

S3 Access Grants READ and READWRITE access levels

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.

Data owners who are not governors can write restricted and , which allow them to enforce policies on multiple data sources simultaneously, eliminating the need to write redundant .

Unlike global policies, the application of these policies is restricted to the data sources owned by the users or groups specified in the policy and will change as users' ownerships change.

Write access policy requirements

• At least one of the following permissions is required to manage write policies:

  • CREATE_DATA_SOURCE Immuta permission (to create local write policies)

  • GOVERNANCE Immuta permission (to create local or global write policies)

  • MANAGE_POLICIES domain permission (to create global write policies)

• , , or integration

• (for Snowflake integrations)

Create a restricted subscription policy

1. Click the Policies in the left sidebar and select Subscription Policies.

2. Click Add Policy, complete the Enter Name field.

3. Select the access type:

   • Read Access: Control who can view the data source.

   • Write Access: Control who can view and modify data in the data source.

4. Select the level of access restriction you would like to apply to your data sources:

   • Allow anyone: Check the Require Manual Subscription checkbox to turn off automatic subscription. Enabling this feature will require users to manually subscribe to the data source if they meet the policy.

   • Allow anyone who asks (and is approved):

     1. Click Anyone or An individual selected by user from the first dropdown menu in the subscription policy builder.

        Note: If you choose An individual selected by user, when users request access to a data source they will be prompted to identify an approver with the permission specified in the policy and how they plan to use the data.

     2. Select the Owner (of the data source), USER_ADMIN, GOVERNANCE, or AUDIT permission from the subsequent dropdown menu.

        Note: You can add more than one approving party by selecting + Add Another Approver.

   • Allow users with specific groups/attributes:

     1. Choose the condition that will drive the policy: when user is a member of a group or possesses attribute. Note: To build more complex policies than the builder allows, follow the policy guide.

     2. Use the subsequent dropdown to choose the group or attribute for your condition. You can add more than one condition by selecting + Add Another Condition. The dropdown menu in the subscription policy builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.

     3. Check the Require Manual Subscription checkbox to turn off automatic subscription. Enabling this feature will require users to manually subscribe to the data source if they meet the policy.

     4. If you would like to make your data source visible in the list of all data sources in the UI to all users, click the Allow Data Source Discovery checkbox. Otherwise, this data source will not be discoverable by users who do not meet the criteria established in the policy.

     5. If you would like users to have the ability to request approval to the data source, even if they do not have the required attributes or traits, check the Request Approval to Access checkbox. This will require an approver with permissions to be set.

     6. Select how you want Immuta to merge multiple global subscription policies that apply to a single data source.

        • Always Required: Users must meet all the conditions outlined in each policy to get access (i.e., the conditions of the policies are combined with AND).

        • Share Responsibility: Users need to meet the condition of at least one policy that applies (i.e., the conditions of the policies are combined with OR).

        Note: To make this option selected by default, see .

   • Allow individually selected users

5. From the Where should this policy be applied dropdown menu, select When selected by data owners, On all data sources, or On data sources. If you selected On data sources, finish the condition in one of the following ways:

   • tagged: Select this option and then search for tags in the subsequent dropdown menu.

   • with columns tagged: Select this option and then search for tags in the subsequent dropdown menu.

   • with column names spelled like: Select this option, and then enter a regex and choose a modifier in the subsequent fields.

   • in server: Select this option and then choose a server from the subsequent dropdown menu to apply the policy to data sources that share this connection string.

   • created between: Select this option and then choose a start date and an end date in the subsequent dropdown menus.

6. Beneath Whose Data Sources should this policy be restricted to, add users or groups to the policy restriction by typing in the text fields and selecting from the dropdown menus that appear.

7. Opt to complete the Enter Rationale for Policy (Optional) field.

8. Click Create Policy, and then click Activate Policy or Stage Policy.

This page details how users can create more complex policies using functions and variables in the Advanced DSL policy builder than the Subscription Policy builder allows.

For instructions on writing Global Subscription Policies, see the following .

Enabling Enhanced Subscription Policy Variables (Public Preview)

1. Navigate to the App Settings Page.

2. Click Advanced Settings in the left panel, and scroll to the Preview Features section.

3. Check the Enable Enhanced Subscription Policy Variables checkbox.

4. Click Save.

Create and Edit Global Subscription Policies Using Advanced DSL

1. Navigate to the Policies Page.

2. Select Subscription Policies and click + Add Subscription Policy.

3. Choose a name for your policy and select how the policy should grant access.

4. Select Create using Advanced DSL.

5. Select the rules for your policy from the Advanced DSL options. For example, creating a @hasTagsAsAttribute('Department', 'dataSource') would subscribe all users who have an attribute that matches a tag on a data source to that data source. So users with the attribute Department.Marketing would be subscribed to data sources with the tag Marketing.

6. Check the Require Manual Subscription checkbox to turn off automatic subscription. Enabling this feature will require users to manually subscribe to the data source if they meet the policy.

7. If you would like to make your data source visible in the list of all data sources in the UI to all users, click the Allow Data Source Discovery checkbox. Otherwise, this data source will not be discoverable by users who do not meet the criteria established in the policy.

8. If you would like users to have the ability to request approval to the data source, even if they do not have the required attributes or traits, check the Request Approval to Access checkbox. This will require an approver with permissions to be set.

9. Select how you want Immuta to merge multiple global subscription policies that apply to a single data source.

   • Always Required: Users must meet all the conditions outlined in each policy to get access (i.e., the conditions of the policies are combined with AND).

   • Share Responsibility: Users need to meet the condition of at least one policy that applies (i.e., the conditions of the policies are combined with OR).

10. Select where this policy should be applied, On data sources, When selected by data owners, or On all data sources

    • If a user selects On data sources options include, with columns tagged, with columns spelled like, in server, and created between.

11. Click Create Policy.

Clone a policy

1. Click the Policies icon in the left sidebar and navigate to the Data Policies or Subscription Policies tab.

2. Click the dropdown menu in the Actions column of a policy and select Clone.

3. Open the dropdown menu and click Edit in the Global Policy Builder. Then make your changes using the dropdown menus.

4. Click Create Policy, select Activate Policy, and then click Confirm.

The policy will display as Pending until it is enforced on all data sources it applies to. See the Policies explained guide for details.

Note: If a cloned policy contains custom certifications, the certifications will also be cloned.

Activate a templated policy

1. Click the Policies icon in the left sidebar and navigate to the Data Policies tab.

2. Click the dropdown menu in the Actions column of one of the templated policies and select Activate. Note: If data governors decide to stage an active policy, they select Stage from this dropdown menu.

The policy will display as Pending until it is enforced on all data sources it applies to. See the Policies explained guide for details.

Stage the policy

1. Click the dropdown menu in the Actions column of a policy and select Stage. Note: If data governors decide to make a staged policy active, they select Activate from this dropdown menu.

2. Click Confirm in the dialog that appears.

The policy will display as Pending until it is removed from all data sources it applies to. See the Policies explained guide for details.

There are several different advanced functions that are available for building subscription policies. Some of these functions, listed below, are narrowly focused on orchestrated RBAC use cases. Orchestrated RBAC is when an organization has many roles that represent access, and rather than switching to using the ABAC model provided by Immuta, they use these special functions to orchestrate existing roles using Immuta.

Specifically, the functions to enable orchestrated-RBAC are:

• @hostname

• @database

• @schema

• @table

• @hasTagAsAttribute('Attribute Name', 'dataSource' or 'column')

• @hasTagAsGroup('dataSource' or 'column')

Example 1

Policy:

@hasAttribute('SpecialAccess', '@hostname.@database.*')

User:

has the attribute SpecialAccess with the value us-east-1-snowflake.default.*

The user would be subscribed to all the data sources in the default database. Note this has nothing to do with tags, it is based purely on the physical name of the host, database, schema, and table in the native data platform. Also note that the user attribute contains an asterisk * to denote everything under the default database hierarchy. Asterisks are supported only for the infrastructure special functions:

• @hostname

• @database

• @schema

• @table

This is because, since it's an infrastructure view, Immuta can assume a 4-level hierarchy (hostname.database.schema.table) and an asterisk can be placed between any two objects in that 4-level hierarchy to represent any object, such as us-east-1-snowflake.*.hr. That would give the user access to any schema named hr in host us-east-1-snowflake no matter the database.

However, that is not possible when using the tag-based special functions:

• @hasTagAsAttribute('Attribute Name', 'dataSource' or 'column')

• @hasTagAsGroup('dataSource' or 'column')

This is because Immuta cannot rely on a 4-level hierarchy always being the case. For example, *.Age could mean many things in a tag hierarchy. However it does support using parent attributes to apply to child attributes as described in Example 2.

Lastly, the asterisk represents any object, but cannot be used for a concatenated wildcard like so: snowfl*.tpc.*.*

Example 2

Policy:

@hasTagAsAttribute('PersonalData', 'dataSource')

User:

has the attribute key PersonalData with the values

• Discovered.Person Name

• Discovered.Entity

Data source 1:

tagged:

• Discovered.Country

• Discovered.Passport

• Discovered.Person Name

Data source 2:

tagged:

• Discovered.State

• Discovered.Postal Code

• Discovered.Entity.Social Security Number

Data source 3:

tagged:

• Discovered.State

• Discovered.Passport

The user would be subscribed to data source 1 and 2, but the user would not be subscribed to data source 3. This is because access moves from left-to-right in the hierarchy based on what the user possesses (the wildcard asterisk is implied).

So if a user had a more specific attribute key PersonalData with the values Discovered.Entity.Social Security Number, they would only get access to hypothetical data source 2, because their attribute is further left or matches (in this case matches) Discovered.Entity.Social Security Number.

The below table provides more examples:

Merging special functions

It is also possible to build subscription policies separately that use these special functions and have them merge appropriately on data sources.

This could be helpful for use cases with a policy like the following:

If user has the attribute “Allowed_Domain.Domain A” they get access to generic data that is part of domain A.

If user has the attribute “Badge_Allowed.Badge X” they should gain access to both “generic data + any additional data (only in domain A because they only have “Data Domain A General Access”) that has been tagged as “Badge X”.

In this case it can be two separate subscription policies, such as

Policy 1: @hasTagAsAttribute(Allowed_Domain, ‘datasource’) this would limit to the domains where they are allowed to see generic data.

Policy 2: @hasTagAsAttribute(Badge_Allowed, ‘datasource’) this would limit to the badges they are allowed to see.

Then, when the data sources are tagged with table tags that represent access, if the table only has the domain tag, only policy 1 will apply; however, if it has a domain tag and a badge tag, both policies will be applied and merged successfully by Immuta.

Use with caution

While this approach is extremely powerful, in many cases, it will continue to leave you dealing with policy complexity associated with RBAC. Read the Automate data access control decisions use case for more details, specifically The two paths guide.