Subscription Policies Reference Guide

Subscription policies manage table-level access to data. Governors, data source owners, or domain policy managers manage table access by authoring subscription policies that grant access or subscription policies that prevent it using one of the two subscription policy types:

Grant subscription policy

These subscription policies grant users read or write access to the data source when they meet the conditions of the policy.

You can provide access at one of four restriction levels:

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

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

Example policy: Allow anyone who asks and is approved to subscribe with read access when approved by anyone with permission GOVERNANCE.

Guardrail subscription policy

These subscription policies prevent read or write access unless users meet the conditions of the policy. Unlike grant policies, guardrail policies do not subscribe users; they act as the minimum requirements that must be met before a user is eligible to subscribe to the data source.

If the conditions of a guardrail policy are not met, users will not be subscribed to the data source even if they meet conditions of a grant policy on the data source. Consequently, you can delegate access management to your domain and data owners to allow them to apply additional access rules to data they manage, and guardrail policies will ensure that certain rules can never be overridden by those users, . For examples of how these policies are applied and grant access to data, see the Policy merging section.

You can create a guardrail policy at a single restriction level:

• Users with specific groups or attributes. Only users with the specified groups/attributes are eligible to subscribe to the data source. This restriction type is referred to as an .

Example policy: Allow users to subscribe when user is a member of group Training.

Multiple policies on a single data source

More than one policy may apply to a data source. When this happens, the policies will either merge or conflict, depending on the type of subscription policies they are and their restriction levels:

• will merge with each other. See the section below for details about how they will merge.

• Subscription policies of the restriction levels listed below will conflict:

  • Anyone

  • Anyone who asks (and is approved)

  • Individual users you select

  See the section below for details about policy conflicts and how to handle them.

Policy merging

ABAC subscription policies merge with AND or OR, depending on whether they are grant or guardrail subscription policies:

• Grant policies combine with OR: When multiple ABAC policies that grant access apply to a single data source, they combine with OR, so the conditions of one of the policies must be met for a user to be subscribed to the data source.

• Guardrail policies combine with AND: When multiple guardrail policies apply to a data source, they combine with AND, so the conditions of all guardrail policies must be met for users to be eligible to subscribe to the data source. Guardrail policies only merge with other guardrail policies or global ABAC policies that grant access. See the section below for details about what happens if other policy types apply to a data source.

Expand the collapsible blocks below to see illustrations of how user access is provided or prevented when multiple policies apply to a data source:

1 grant policy and 1 guardrail policy

The table below illustrates the access decisions for three users who have different entitlements for a data source that has one policy that provides access and one policy that prevents access applied to it.

	Grant policy: Allow users to subscribe when user is a member of HR.	Guardrail policy: Prevent users from subscribing unless user has completed Training.	Access result
User A entitlements HR Training	✅	✅	✅
User B entitlement HR	✅	⛔	⛔
User C entitlement Training	⛔	✅	⛔

In this scenario, User A is the only user who is granted access to the data source because they meet the condition of the guardrail policy and the grant policy.

User B has the HR entitlement, but that user is not subscribed to the data source because the guardrail policy only allows users who have the Training entitlement to ever be subscribed. However, if that user completes their training and receives the Training entitlement, they will be eligible to access the data and will be subscribed to the data source by the grant policy that provides access with the HR entitlement.

Although User C has completed their training and is eligible to subscribe, they were not subscribed to the data source because they do not have the HR entitlement.

2 grant policies and 1 guardrail policy

When multiple grant policies apply to a data source, users only have to meet the criteria outlined in one of those grant policies, but the criteria in the guardrail policies are always required.

Consider the table below, which shows what happens when two different policies that grant access (one requiring the HR entitlement and another requiring the Executive entitlement) and one guardrail policy apply to the same data source.

	Grant policy: Allow users to subscribe when user is a member of HR.	Grant policy: Allow users to subscribe when user is a member of Executive.	Guardrail policy: Prevent users from subscribing unless user has completed Training.	Access result
User A entitlements HR Training	✅	⛔	✅	✅
User B entitlement HR	✅	⛔	⛔	⛔
User C entitlement Training	⛔	⛔	✅	⛔
User D entitlements Executive Training	⛔	✅	✅	✅

In this example, User A and User D are both granted access to the data source because

• they both have the Training entitlement AND

• they have either the HR entitlement OR the Executive entitlement

User B has the HR entitlement, but that user is not subscribed to the data source because the guardrail policy only allows users who have the Training entitlement to ever be subscribed. However, if that user completes their training and receives the Training entitlement, they will be eligible to access the data and will be subscribed to the data source by the grant policy that provides access with the HR entitlement.

Although User C has completed their training and is eligible to subscribe, they were not granted access because they do not have the HR or Executive entitlement.

1 grant policy and 2 guardrail policies

When multiple guardrail policies apply to a data source, users have to meet the criteria in all of those guardrail policies to be eligible to subscribe.

Consider the table below, which shows how access is determined when two different guardrail policies (one requiring the Training entitlement and the other requiring the Accountant_level.2 entitlement) and one grant policy apply to the same data source.

	Grant policy: Allow users to subscribe when user is a member of HR.	Guardrail policy: Prevent users from subscribing unless user has completed Training.	Guardrail policy: Prevent users from subscribing unless user is Accountant_level.2.	Access result
User A entitlements HR Training	✅	✅	⛔	⛔
User B entitlement HR	✅	⛔	⛔	⛔
User C entitlement Training	⛔	✅	⛔	⛔
User D entitlements HR Training Accountant_level.2	✅	✅	✅	✅

In this example, only User D is granted access because they are the only user who has the HR entitlement and both the Training and the Accountant_level.2 entitlements.

2 grant policies and 2 guardrail policies

When multiple grant policies and multiple guardrail policies apply to a data source,

• users must meet the criteria outlined in one of the grant policies and

• users must meet the criteria in all of the guardrail policies to subscribe.

Consider the table below, which shows how access is determined when two different grant policies (one requiring the HR entitlement and one requiring the Executive entitlement) and two different guardrail policies (one requiring the Training entitlement and the other requiring the Accountant_level.2 entitlement) apply to the same data source.

	Grant policy: Allow users to subscribe when user is a member of HR.	Grant policy: Allow users to subscribe when user is a member of Executive.	Guardrail policy: Prevent users from subscribing unless user has completed Training.	Guardrail policy: Prevent users from subscribing unless user is Accountant_level.2.	Access result
User A entitlements HR Training	✅	⛔	✅	⛔	⛔
User B entitlement HR	✅	⛔	⛔	⛔	⛔
User C entitlement Training	⛔	⛔	✅	⛔	⛔
User D entitlements HR Executive Training Accountant_level.2	✅	✅	✅	✅	✅
User E entitlements Executive Training Accountant_level.2	⛔	✅	✅	✅	✅

In this example, only User D and User E are granted access because they are the only users who have

• HR OR Executive entitlement and

• Training AND Accountant_level.2 entitlements.

Policy conflicts

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:

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.

Guardrail subscription policies

Guardrail subscription policies will be disabled when they are overwritten by data owners with a local policy or if they conflict with a global policy at any of the restriction levels below:

• Anyone

• Anyone who asks (and is approved)

• Individual users you select

To be notified when a policy that prevents access is disabled, create a webhook that includes the policyUpdated notification type:

1. Create a webhook that will trigger on the policyUpdated notification.

   curl -X 'POST' \
       'https://www.organization.immuta.com/webhooks' \
       -H 'accept: application/json' \
       -H 'Content-Type: application/json' \
       -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
       -d '{
       "webhooks": [
         {
           "url": "https://demo.service.com/processWebhook",
           "name": "Policy updated",
           "global": false,
           "notificationType": [
             "policyUpdated"
           ],
           "actionType": "triggered"
         }
       ]
     }'

2. Compare the old policy object with the new policy object to determine whether or not a policy that prevents access was overwritten. The scenarios below indicate that a policy that prevents access has been disabled on the data source:

old has "mergedGuardrail": true, but new does not

In the example below, the old policy object includes "mergedGuardrail": true , which indicates that it included a policy that prevented access. This policy has been overwritten by a new policy object: an automatic subscription policy that does not have a mergedGuardrail attribute, indicating that the policy that prevented access has been disabled.

{
  "dataSourceName": "Public Case",
  "triggeredByGlobal": false,
  "conflictCount": 1,
  "policyType": "subscription",
  "handlerId": 5,
  "previousHandlerId": 5,
  "dataSourceType": "queryable",
  "disabledSubscriptionPolicies": 4,
  "subscriptionPolicyChanges": {
    "old": {
      "subscriptionType": "policy",
      "subscriptionPolicy": {
        "type": "subscription",
        "advanced": "(@isInGroups('Training complete')) AND (@isInGroups('HR')) AND ((@isInGroups('HR')))",
        "accessGrant": "READ",
        "description": "",
        "allowDiscovery": false,
        "mergedGuardrail": true,
        "subscriptionType": "policy",
        "automaticSubscription": true
      }
    },
    "new": {
      "subscriptionType": "automatic",
      "subscriptionPolicy": {
        "type": "subscription",
        "accessGrant": "READ",
        "description": null,
        "allowDiscovery": false,
        "subscriptionType": "automatic",
        "shareResponsibility": true,
        "automaticSubscription": true
      }
    }
  }
}

old includes "subscriptionType": "guardrail", but new does not AND new does not have mergedGuardrail

In the example below, the old policy object includes "subscriptionType": "prevent" , which indicates that it is a policy that prevents access. This policy has been overwritten by a new policy object with "subscriptionType": "none", indicating that the policy that prevents access has been disabled and there is no subscription policy on the data source.

{
  "dataSourceName": "Public Case",
  "triggeredByGlobal": false,
  "conflictCount": 1,
  "policyType": "subscription",
  "handlerId": 5,
  "previousHandlerId": 5,
  "dataSourceType": "queryable",
  "disabledSubscriptionPolicies": 4,
  "subscriptionPolicyChanges": {
    "old": {
      "subscriptionType": "guardrail",
      "subscriptionPolicy": {
        "type": "subscription",
        "advanced": "(@isInGroups('engineers')) AND ((@isInGroups('engineers')))",
        "accessGrant": "READ",
        "description": "",
        "allowDiscovery": false,
        "subscriptionType": "guardrail",
        "shareResponsibility": false,
        "automaticSubscription": false
      }
    },
    "new": {
      "subscriptionType": "none",
      "subscriptionPolicy": null
    }
  }
}

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 if you want to manage table access outside of Immuta but want to manage data policies in Immuta.

Databricks Unity Catalog behavior

If a securable has been registered as an Immuta data source, users who are registered in Immuta and who are not subscribed to the data source (either manually or by a subscription policy) will have their access REVOKED, even if they had been directly granted access to the table in Unity Catalog.

If a user is not registered in Immuta, Immuta will have no effect on that user's access to data in Unity Catalog.

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.