Policy Boolean Logic
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.
It’s recommended, but not required, that you also complete the Separating Policy Definition from Role Definition: Dynamic Attributes walkthrough.
Overview
The use case for this walkthrough is fairly simple, but unachievable in most role-based access control models. Long story short, the only way to support AND boolean logic with a role-based model is by creating a new role that conflates the two or more roles you want to AND together.
Let’s take an example: we want users to only see certain data if they have security awareness training AND have consumer privacy training. It would be natural to assume you need both separately as metadata attached to users to drive the policy, but when you build policies in a role based model, it assumes roles are either OR’ed together in the policy logic or you can only act under one role at a time, and because of this, you will have to create a single role to represent this combination of requirements “users with security awareness and consumer privacy training”. This is completely silly and unmanageable - you need to account for every possible combination relevant to a policy, and you have no way of knowing that ahead of time.
We go over the benefits of an attribute-based access control model over a role-based model ad nauseam in the Separating Policy Definition from Role Definition: Dynamic Attributes walkthrough if you have not done that yet and want more details. (We recommend you do if this walkthrough is of interest to you.)
Business Value
If you only have to manage 7 understandable attributes/roles vs 700 - wouldn’t you want to? That’s the real value here.
Scalability: Far fewer roles to manage.
Understandability: Policies (and roles) are clearly understood. No one super user is required to explain what is going on.
Evolvability: No fear of making changes, changes are made easily, again, without the need for super user tribal knowledge.
Durability: Changes in data and users will not result in data leaks.
Because of this, the business reaps
Increased revenue: accelerate data access / time-to-data.
Decreased cost: operating efficiently at scale, agility at scale.
Decreased risk: prove policy easily, avoid policy errors.
Build a row-level policy with an AND condition
Assumptions: Your user has the following permissions in Immuta (note you should have these by default if you were the initial user on the Immuta install):
GOVERNANCE: in order to build policy against any table in Immuta OR are a “Data Owner” of the registered tables. (You likely are the Data Owner and have GOVERNANCE permission.)
USER_ADMIN: in order to manage groups/attributes on users.
Give yourself (and other users) attributes
We need to have attributes or groups assigned to you to drive policy. With Immuta these can come from anywhere (we mean literally anywhere), and Immuta will aggregate them to use in policy. Most commonly these come from your identity manager, such as LDAP, Active Directory, Okta, etc., but for simplicity sake, we are going to assign attributes to you in Immuta.
Click the People icon and select Users in the left sidebar.
Select your name and click + Add Attributes.
In the Add Attributes modal, type Training Accomplished in the Attribute field and click Create.
In the Attribute value field, create these two values: Security Awareness and Consumer Privacy.
Repeat these steps for the non-admin user you created in Part 3 of the POV Data Setup. However, give that user
Attribute: Training Accomplished
Attribute value: Security Awareness
Notice that second user does not have Consumer Privacy training.
Build the row-level policy
Click the Policies icon in the left sidebar of the Immuta console.
On the Data Policies tab, click + Add Data Policy.
Name the policy: RLS and condition.
Select the action: Only show rows.
Select the sub-action: where.
Set the where clause as: salary < 200000.
Leave for everyone except, and change the exception to
possesses attribute
Training Accomplished
Security Awareness
Click + Add Another Condition.
Make sure the logic is and
Possesses attribute
Training Accomplished
Consumer Privacy
Click Add.
Under, Where should this policy be applied?, select
On Data Sources
with column names spelled like
salary
Don’t select any modifiers. We did it this way because the salary column has no column tags we can use. (We could have added a tag to it, though, if we wanted.)
Click Create Policy and then Activate Policy.(Ignore any warnings of policy overlap.)
Following the Query Your Data guide, test that your user sees the rows with salary above 200000 because you have both trainings and your non-admin user only sees rows with a salary under 200000 because they only have one of the two required trainings.
Anti-Patterns
This is just another example of why role-based policy management can get you in trouble. This problem specifically leads to an industry phenomenon termed “role explosion.” Roles must account for every possible combination of requirements for a policy since that logic cannot be prescribed as an AND condition.
Almost every database follows a role-based model, including legacy policy engines such as Apache Ranger. For example, with Snowflake you can only act under one role at a time, so all policy logic must consider that, in Databricks you may have multiple groups that are all assumed, but the methods for defining policy do not allow AND logic against those groups. This same problem holds true for Ranger policy logic.
The answer is an attribute based model where you can separate defining policy from defining user and data metadata, providing scalability and avoiding role explosion. We have seen this in real customer use cases. In one great example we required 1 policy in Immuta for the equivalent controls requiring 96 rules in Ranger.
For more reading on the RBAC anti-pattern: Data Governance Anti-Patterns: Stop Conflating Who, Why, and What
More reading on RBAC vs ABAC in general: Role-Based Access Control vs. Attribute-Based Access Control — Explained
And if you really want to go deep, NIST on ABAC: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
Next Steps
Feel free to return to the POV Guide to move on to your next topic.
Last updated