Overview

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 governance 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 data source (even if an ABAC subscription policy is also present) they will conflict:

• Anyone

• Anyone who asks (and is approved)

• Individual users you select

When such conflicts occur, Immuta sorts the relevant policies by name in descending lexicographical order and applies the first policy in the sorted list. For example, if a policy named "HR access" and a policy named "Executive access" apply to a data source, Immuta will automatically apply the "HR access" policy to the data source.

Renaming conflicting subscription policies could alter policy application

Because Immuta resolves non-ABAC subscription policy conflicts by policy name, renaming a subscription policy could change which policy Immuta applies.

In the example above, Immuta applied the "HR access" subscription policy to the data source when it conflicted with the "Executive access" subscription policy. If a governor changed the policy name to "Access for HR," Immuta would apply the "Executive access" subscription policy to the data source.

However, 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. Data governors and owners can create global subscription policies using all the functions and variables outlined below.

Variable/Function	Description	Example
@database	Users who have an attribute key that matches a database will be subscribed to the data source(s) within the database.	@hasAttribute('SpecialAccess', '@hostname.@database.*'): If a user had the attribute SpecialAccess: us-east-1-snowflake.default.*, they would get subscribed to all the data sources in the default database.
@hasAttribute('Attribute Name', 'Attribute Value')	Users who have the specified attribute are subscribed to the data source.	@hasAttribute('Occupation', 'Manager'): Any user who has the attribute Occupation and the attribute key Manager will be subscribed to the data source(s).
@hasTagAsAttribute('Attribute Name', 'dataSource' or 'column' )	Users who have an attribute key that matches a tag on a data source or column will be subscribed to that data source.	@hasTagAsAttribute('PersonalData', 'dataSource'): Users who have the attribute key PersonalData with the values Discovered.Passport,Discovered.Entity would be subscribed to Data Source 1, which is tagged:[Discovered.Passport] and Data Source 2, which is tagged:[Discovered.Entity]. However, they would not be subscribed to Data Source 3, which is tagged: [Discovered.Country].
@hasTagAsGroup('dataSource' or 'column' )	Users who are members of a group that matches a tag on a data source or column (respectively) will be subscribed to that data source.	@hasTagAsGroup('dataSource'): If Data Source 1 has the tags NewHire and Interns applied, users who are members of the groups New Hire or Interns would be subscribed to Data Source 1.
@hostname	Users who have an attribute key that match a hostname will be subscribed to the data source(s) with that hostname.	@hasAttribute('SpecialAccess', '@hostname.*'): If a user had the attribute SpecialAccess : us-east-1-snowflake.*, they would get subscribed to all the data sources with the us-east-1-snowflake hostname.
@isInGroups('List', 'of', 'Groups')	Users who are members of the specified group(s) can be subscribed to the data source.	@isInGroups('finance','marketing','newhire'): Users who are members of the groups finance, marketing, or newhire can be subscribed to the data source.
@schema	Users who have an attribute key that match this schema will be subscribed to the data source(s) under that schema.	@hasAttribute('SpecialAccess', '@hostname.@database.@schema'): If a user had the attribute SpecialAccess : us-east-1-snowflake.default.public.*, they would get subscribed to all the data sources under the public schema.
@table	Users who have an attribute key that match this table will be subscribed to the data source(s).	@hasAttribute('SpecialAccess', '@hostname.@database.@schema.@table'): If a user had the attribute SpecialAccess : us-east-1-snowflake.default.public.credit_transactions, they would get subscribed to the credit_transactions data source.

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.

Managing data policies when there is no subscription policy

Immuta does not apply subscription policies on registered data sources unless existing global policies apply to them.

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.