Skip to content

You are viewing documentation for Immuta version 2023.4.

For the latest version, view our documentation for Immuta SaaS or the latest self-hosted version.

cancel

Subscription Policies: Benefits of Attribute-Based Table GRANTs

Prerequisite: Before using this walkthrough, please ensure that you’ve first done the Parts 1-5 of the POV Data Setup and the Schema Monitoring and Automatic Sensitive Data Discovery walkthrough.

Overview

There are a myriad of techniques and processes companies use to determine what users should have access to which tables. We’ve seen 7 people having to respond to an email chain for approval before a DBA runs a table GRANT statement, for example. Manual approvals are sometimes necessary, of course, but there’s a lot of power and consistency in establishing objective criteria for gaining access to a table rather than subjective human approvals.

Let’s take the “7 people approve with an email chain” example. We like to ask the question: “why do any of you 7 say yes to the user gaining access?” If it’s objective criteria, you can completely automate this process. For example, if the approver says, “I approve them because they are in group x and work in the US,” that is user metadata that could allow the user to automatically gain access to the tables, either ahead of time or when requested. This removes a huge burden from your organization and avoids mistakes. Note that many times it can be the purpose of what the user is working on that drives if they should have access or not; we cover that in our purpose exceptions walkthrough next.

Business Value

Being objective is always better than subjective: it increases accuracy, removes bias, eliminates errors, and proves compliance. If you can be objective and prescriptive about who should gain access to what tables - you should.

Because of this, the business reaps

  • Increased revenue: accelerate data access / time-to-data, no waiting for humans to make decisions.
  • Decreased cost: operating efficiently at scale, agility at scale because humans are removed from the daily approval flows.
  • Decreased risk: avoid policy errors through subjective bias and mistakes.

Building Immuta subscription policies

Assumptions: Your user has one of the following permissions in Immuta. (Note that you should have these by default if you were the initial user on the Immuta installation):

  • GOVERNANCE: in order to build policy against any table in Immuta
  • “Data Owner” of the registered tables (you likely are the Data Owner and have GOVERNANCE permission).

Up until now we’ve only talked about data policies, which limit what users see WITHIN a table. Subscription policies manage who can see what tables, similar to table GRANTs you may already be familiar with.

Immuta supports multiple modes of subscription policies:

  • Allow anyone: This is where anyone can access the table. (We did this in Part 5 of the POV Data Setup.)
  • Allow anyone who asks (and is approved): These are manual subjective approvals.
  • Allow users with specific groups/attributes: These are objective policies for access that we will walk through.
  • Allow individually selected users: This is just like database GRANTs, the table is hidden until a user or group is manually granted access.

As you can see, Immuta does support subjective approvals through “Allow anyone who asks (and is approved)” because there are some regulatory requirements for them, although we’d argue this is an anti-pattern. To show you the power of objective subscription policies, we’ll walk through “Allow users with specific groups/attributes” policy building.

Following the Query Your Data guide, confirm that both your user and the non-admin user you created in Part 3 of the POV Data Setup can query any POV table (“Fake HR Data” or “Fake Credit Card Transactions”). Both can query them due to the “Allow anyone” subscription policy you created in Part 5 of the POV Data Setup; otherwise, the non-admin user would not have been able to query it. We are going to edit that policy to change it to an “Allow users with specific groups/attributes” policy.

  1. Click the Policies icon in the left sidebar of the Immuta console.
  2. Click the Subscription Policies tab at the top. You should see the “Open Up POV Data” subscription policy you created in Part 5 of the POV Data Setup.
  3. Edit the Open Up POV Data subscription policy by clicking the menu button on its right and selecting Edit.
  4. Change How should this policy grant access? from Allow anyone to Allow users with specific groups/attributes.

  5. For Allow users to subscribe when user, select the condition

    • possesses attribute
    • Key: Country
    • Value: JP (Remember, you created this attribute in the Schema Monitoring and Automatic Sensitive Data Discovery walkthrough.)

  6. At this point there are several other settings for this policy. For the purposes of this walkthrough, leave all of the below options unchecked.

    • Allow Discovery: Users who don’t meet the policy (don’t have Country JP in this case) will still be able to see/discover this table in the Immuta UI, otherwise it will be hidden.
    • Require users to take action to subscribe: If left unchecked (the default) users will automatically be subscribed to the table when the policy is activated or when they reach a state (get Country JP) that allows them to be subscribed. If checked, the user would visit the data source page in the catalog and request a subscription (and be immediately added because they meet the policy).
    • On merge, allow shared policy responsibility: This will allow other data owners or governors to build policies against these tables as alternatives to your policy (essentially additional policies are OR'ed rather than AND'ed).

  7. Leave the Where should this policy be applied? as is.

  8. Click Save Policy.

Following the Query Your Data guide, confirm that now your admin user with Country JP can see any POV table (“Fake HR Data” or “Fake Credit Card Transactions”); however, the non-admin user you created in Part 3 of the POV Data Setup with only Country US cannot query either table (in some cases, based on enforcement, the user can query the table, but they just won’t get any data back). You can also look at any of the “Members” tab of the data source in the Immuta UI and see your non-admin user has been removed. Additionally, if you log in to Immuta as your non-admin user, you will notice all those tables are gone from the catalog.

Now let’s go back and make it so the non-admin user you created in Part 3 of the POV Data Setup can see the tables again:

  1. Click the Policies icon in the left sidebar.
  2. Click the Subscription Policies tab at the top.
  3. Edit the Open Up POV Data subscription policy again by clicking the menu button on its right and selecting Edit.
  4. Click + Add Another Condition.
  5. Change and to or” (IMPORTANT).
  6. Select the condition
    • possesses attribute
    • Key: Country
    • Value: US
  7. Leave everything else as is and click Save Policy.

Following the Query Your Data guide, confirm both users can see the tables again.

Anti-Patterns

The anti-pattern is manual approvals. We understand that there are some regulatory requirements for this, but if there’s any possible way to switch to objective approvals, you should do it. With subjective human-driven approvals, there is bias, larger chance for errors, and no consistency - this makes it very difficult to prove compliance and is simply passing the buck (and risk) to the approvers and wasting their valuable time.

One could argue that it’s subjective or biased to assign a user the Country JP attribute. This is not true, because, remember, we separated the data policy from user metadata. The act of giving a user the Country JP attribute is simply defining that user, there is no implied access given to the user from this act and that attribute will be objective - e.g., you know if they are in JP or not.

As we’ve seen in our other anti-patterns, the approach where an access decision is conflated with a role or group is common practice (Ranger, Snowflake, Databricks, etc). So not only do you end up with manual approval flows, but you also end up with role explosion from so many roles to meet every combination of access, as we described in the Policy boolean logic walkthrough. If you want a real life example of this in action, you can watch a financial institution’s YouTube video about a software product they built whose sole purpose was to help users understand what roles they needed to request access to (through manual approval) in order to get to the data they needed - they had so much role explosion they had to build an app to handle this.

Next Steps

Feel free to return to the POV Guide to move on to your next topic.