Skip to content

Managing ABAC Policies

Privacera builds on Apache Ranger's ABAC capabilities and provides an intuitive interface to manage these policies for various access control scenarios. This section outlines how to author and manage ABAC-enabled policies across different policy types.

Supported Policy Types for ABAC

ABAC logic can be incorporated into the following policy types in Privacera:

Policy Type ABAC Usage Areas
Resource Access Policy Policy Conditions using user/group/role attributes
Row-Level Filter Policy Expressions using user attributes or group membership
Column Masking Policy Masking conditions based on user or group attributes

Where ABAC Expressions Are Used

ABAC expressions can be applied in the following parts of a policy:

Policy Component ABAC Usage Example
Policy Conditions Boolean expressions using user/group/role/tag macros IS_IN_GROUP('finance')
Row Filters Filter rows dynamically based on user or group attributes dept_code == ${{USER.department}}
Masking Conditions Conditionally mask column values based on user or group metadata CASE WHEN role == '${{USER.role}}' THEN {col} ELSE 'MASKED' END
Dynamic Resource Names Construct policy-scoped resources using user attributes /home/${{USER.dept}}

Creating ABAC Policies in Privacera

ABAC policies can be created in Privacera using the following methods:

  1. Privacera Portal: UI to define and manage ABAC policies interactively.
  2. Apache Ranger REST API: A programmatic interface for creating ABAC policies

Using the Privacera Portal

To create an ABAC-based Access Policy in the UI:

  1. Go to Access Management > (e.g., Databricks Unity Catalog, Snowflake, S3).
  2. Click + Add Policy.
  3. Define the resource (e.g., database, table, path).
  4. Under Allow Conditions, click Add Conditions.
  5. Add Policy Conditions using ABAC macros (e.g., ${{USER.dept}} == 'finance').
  6. Save the policy.

For ABAC-based Row-Level Filters, Masking, or Tag-Based Policies, follow the same top-level navigation ( Access Management), but choose the relevant Policy Type tab (e.g., Row Filter, Masking, or Tag Policies) and configure dynamic expressions accordingly.

Row-Level Filtering and Masking policies require access policies to be created first for the same resource.

  • Row-Level Filtering and Masking policies are dependent on the resource access policies (using resource or tag based policies). Ensure that the resource access policies are created before creating Row-Level Filtering and Masking policies.
  • For ABAC policies, it is common to use group public as the principal in the policy. This will apply to all users, but the ABAC conditions will restrict access based on user attributes.

Example 1: Resource Access Based on User Attributes

Use Case: Allow access to the finance_db database only to users whose department is finance.

Steps:

  • Go to: Access Management > Snowflake
  • Resource:
    • database: finance_db
  • Allow Condition: ${{USER.department}} == 'finance'
JSON
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
  "service": "snowflake",
  "name": "finance-db-access",
  "policyType": 0,
  "resources": {
    "database": {
      "values": ["finance_db"],
      "isExcludes": false,
      "isRecursive": false
    }
  },
  "policyItems": [
    {
      "accesses": [{ "type": "select", "isAllowed": true }],
      "conditions": [
        {
          "type": "custom",
          "values": ["${{USER.department}} == 'finance'"]
        }
      ]
    }
  ],
  "isAuditEnabled": true
}

Result: Only users with the user attribute department=finance can access this database.

Example 2: Row-Level Filtering Based on Region

Use Case: Allow users to only view rows where the region column matches their assigned region.

Steps:

  • Go to: Access Management > Snowflake

  • Resource:

  • database: sales_db, table: orders

  • Row-Level Filter Expression: region = ${{USER.region}}
JSON
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
{
  "service": "snowflake",
  "name": "regional-row-filter",
  "policyType": 2,
  "resources": {
    "database": { "values": ["sales_db"] },
    "table": { "values": ["orders"] }
  },
  "rowLevelPolicies": [
    {
      "rowFilterExpr": "region = ${{USER.region}}"
    }
  ],
  "isAuditEnabled": true
}

Result: Users see only the rows belonging to their assigned region.

Example 3: Column Masking Based on Clearance Level

Use Case: Mask ssn column unless the user's clearance level is high.

Steps:

  • Go to: Access Management > Snowflake
  • Resource: database: customer_db, table: profiles, column: ssn

  • Masking Expression:

    Group Condition Apply Masking
    public \CASE WHEN clearance='${{USER.clearance}}' THEN {col} ELSE 'MASKED' END MASKED

json { "service": "snowflake", "name": "ssn-masking", "policyType": 1, "resources": { "database": { "values": ["customer_db"] }, "table": { "values": ["profiles"] }, "column": { "values": ["ssn"] } }, "dataMaskPolicyItems": [ { "dataMaskInfo": { "dataMaskType": "CUSTOM", "valueExpr": "CASE WHEN clearance='${{USER.clearance}}' THEN {col} ELSE 'MASKED' END" } } ], "isAuditEnabled": true }

Result: Users without high clearance will see 'MASKED' instead of actual SSNs.

Example 4: Tag-Based Access with Group Condition

Use Case: Allow access to any column tagged as PII only if the user belongs to the pii_access group.

Steps:

  • Go to: Access Management > Tag Policies
  • Tag: PII
  • Policy Condition: IS_IN_GROUP('pii_access')

json { "service": "privacera_tag", "name": "pii-access-policy", "policyType": 0, "resources": { "tag": { "values": ["PII"] } }, "policyItems": [ { "accesses": [{ "type": "select", "isAllowed": true }], "conditions": [ { "type": "custom", "values": ["IS_IN_GROUP('pii_access')"] } ] } ], "isAuditEnabled": true }

Result: Only members of the pii_access group can view PII-tagged columns.

Example 5: Dynamic Resource Path Based on User Attribute

Use Case: Grant access only to the S3 path that corresponds to a user's department.

Steps:

  • Go to: Access Management > S3
  • Resource Path: /data/${{USER.department}}/*
  • Allow All Access

json { "service": "s3", "name": "departmental-access", "policyType": 0, "resources": { "path": { "values": ["/data/${{USER.department}}/*"], "isExcludes": false, "isRecursive": true } }, "policyItems": [ { "accesses": [{ "type": "read", "isAllowed": true }] } ], "isAuditEnabled": true }

Result: A user from the engineering department will only have access to /data/engineering/.

Example 6: Allow Access Only if User's Sensitivity Level ≥ Tag Level

Use Case: Enforce sensitivity alignment between user attribute and tag on the resource.

Steps:

  • Go to: Access Management > Tag Policies
  • Tag: SENSITIVE
  • Policy Condition: ${{USER.allowedLevel}} >= TAG.sensitivityLevel

json { "service": "tag", "name": "sensitivity-check", "policyType": 0, "resources": { "tag": { "values": ["SENSITIVE"] } }, "policyItems": [ { "accesses": [{ "type": "select", "isAllowed": true }], "conditions": [ { "type": "custom", "values": [USER.allowedLevel==TAGS.SENSITIVE.sensitivityLevel] } ] } ], "isAuditEnabled": true }

Result: Only users with a sufficiently high clearance level can access the tagged data. Created SENSITIVE TAG in Tag Management with attribute key as

img_6.png

Tagged resource with this tag with appropriate attribute values img_7.png

Created sally user with the attribute key as allowedLevel and value as high img_8.png

Added policy condition in the Access resource policy as below img_9.png

Comments