Skip to main content

Privacera Documentation

Table of Contents

Configure policy with Attribute-Based Access Control on Privacera Platform

Privacera enables use of user, group and tag attributes in authorization policies. Attribute-Based Access Control (ABAC) makes it possible to express authorization policies without prior knowledge of specific resources or specific users, which helps avoid the need for new policies as new resources or users are introduced.

For more information, see How polices are evaluated.

Overview

The following scenarios can be accomplished with ABAC configuration:

ABAC in row filter expressions

By using Attribute-Based Access Control (ABAC) for row filters, user can define attribute based conditions in row filter expressions. For example, user/group attributes can be referenced in a row filter expression:

dept = ${{USER.dept}}
state in ( ${{GET_UG_ATTR_Q_CSV('state')}} )

ABAC in resource definitions

Attributes can also be included in resource names:

path: /home/${{USER._name}}
path: /departments/${{USER.dept}}
database: dept_${{USER.dept}}p

ABAC in policy conditions in Resource based access policies

With the ABAC feature, you can configure resource policies based on user attributes from your LDAP or AD service.

You can assign attributes to users, groups and tags in policies. You can also implement logical conditions on the user attributes for the resource policies.

Attributes can be referenced using expressions:

USER.employeeType != 'intern'

TAG.piiType == 'email'

TAG.sensitivityLevel <= USER.allowedSensitivityLevel

Note

ABAC for policy conditions in resource-based access policies is supported for the following data sources:

  • Databricks/EMR Hive, Spark, and all services using privacera_hive service definitions.

  • PolicySync Snowflake

Prerequisites

Ensure the following prerequisites are met:

  • Import the users from the LDAP or AD directory to the Privacera Ranger database.

    If you have not imported LDAP users yet, see LDAP UserSync integration on Privacera Platform for information.

  • Determine the resources you want to protect with ABAC-based policies.

Setup User/Group Attributes

The users and groups with their attributes can be synced with Usersync from LDAP or AD. With users, the user attributes are also synced from source (such as LDAP or AD).

Note

If any attribute is added or updated to the group public, these attributes cannot be used in ABAC expressions.

Add/Edit Attributes

For more information, see Users, groups, and roles

Example policy with ABAC

  1. Let's say we have a user with the following attribute: dept : IT

  2. We create a resource access policy such as:

    Policy Details

    Policy Name

    access

    Normal Enabled

    Hive Database

    hive_test

    Include

    Hive Table

    employee

    Include

    Hive Column

    *

    Include

    Description

    Audit Log

    Yes

    Policy Labels

    --

    Allow Conditions

    Select Role

    Select Group

    Select User

    Policy Conditions

    Permissions

    Delegate Admin

    tejas, sally

    select

    (unchecked)

  3. We created a Row Filter Policy as below:

    Policy Name

    employee_rlf

    Normal Enabled

    Hive Database

    hive_test

    Hive Table

    employee

    Description

    Audit Log

    Yes

    Policy Labels

    --

    Row Level Conditions

    Select Role

    Select Group

    Select User

    Policy Conditions

    Access Types

    Row Level Filter

    public

    select

    dept == '${{USER.dept}}'

    Note that the row filter expression used here is: dept == '${{USER.dept}}'

  4. Now the setup is done on EMR Hive. The table hive_test.employee is available on the EMR Hive cluster, with data as below:

    | employee.id  |  employee.name  |  employee.location |  employee.dept  |
+--------------+-----------------+--------------------+-----------------+
| 1            |  manny          |  mumbai            | IT
| 2            |  novak          |  NY                | HR
| 3            |  Pablo          |  Barcelona         | HR
| 4            |  Carlos         |  Mexico            | Support
+--------------+-----------------+--------------------+-----------------+
4 rows selected

  5. The user tejas is available on the EMR cluster to run the query. When select query is executed by tejas:

    | employee.id  |  employee.name  |  employee.location |  employee.dept  |
+--------------+-----------------+--------------------+-----------------+
| 1            |  manny          |  mumbai            | IT
+--------------+-----------------+--------------------+-----------------+
1 row selected