Book a demo

Advanced Use of Special Functions

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. This has nothing to do with tags; it is based purely on the physical name of the host, database, schema, and table in the remote data platform.

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:

User Attributes
Data Source Tags
Subscribed?
Notes

PersonalData: Discovered.Person Name, Discovered.Entity

Discovered.Identifier Indirect, Discovered.Person Name

Yes

Exact match on Discovered.Person Name

PersonalData: Discovered.Entity

Discovered.PHI, Discovered.Entity.Age

Yes

User attribute Discovered.Entity is a hierarchical parent of data source tag Discovered.Entity.Age

Access: Discovered.Person Name, Discovered.Entity

Discovered.Identifier Indirect, Discovered.Person Name

No

The policy is written to only match values under the PersonalData attribute key. Not Access.

PersonalData: Discovered

Discovered.Entity.Age

Yes

User attribute Discovered is a hierarchical parent of data source tag Discovered.Entity.Age

PersonalData: Discovered.Entity.Social Security Number

Discovered.Entity

No

Hierarchical matching only happens in one direction (user attribute contains data source tag). In this case, the user attribute is considered hierarchical child of the data source tags.

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.

Last updated

Was this helpful?