Smart Security — Automating ABAC with Ranger and LDAP Attributes

TL;DR: The Power of ABAC

• The Problem: Role-Based Access Control (RBAC) leads to "Role Explosion." You end up creating hundreds of roles (e.g., Finance-Manager-NY, Finance-Analyst-LDN) just to handle basic permissions.
• The Solution: ABAC (Attribute-Based Access Control). Instead of creating a new role, you tell Ranger: "Let them in IF their LDAP 'Department' is 'Finance' AND their 'Location' matches the data's region."
• The Big Win: Zero-touch security. When a user moves from the London office to New York in Active Directory, their data permissions update automatically. No tickets, no manual role changes.

The Evolution: Moving from "Who" to "What"

In my previous post, we looked at how Ranger uses tags to identify sensitive data. But what about the User?

In a standard setup, we put users into groups. But groups are static. In a modern enterprise, we need to make decisions based on Attributes. This is the core of ABAC. By syncing your LDAP/Active Directory attributes directly into Ranger, you turn your user directory into a dynamic security engine.

How it Works: The LDAP to Ranger Pipeline

1. The Sync (Ranger UserSync)

First, you have to ensure Ranger isn't just pulling usernames, but also their metadata. In the Ranger UserSync configuration, you map LDAP attributes (like department, title, or country) so they appear as "User Attributes" in the Ranger UI.

Tech Tip: Check your ranger-ugsync-site.xml and ensure ranger.usersync.ldap.user.searchfilter includes the attributes you need.

2. Defining the Policy

In the Ranger Policy builder, you no longer just select "Group: Finance." Instead, you use a Policy Condition. You can write a simple expression like: ${USER.department} == 'Finance' && ${USER.location} == 'US'

3. The Result: Dynamic Filtering

Imagine a Hive table containing global sales data. With ABAC, you only need one policy.

• If Rizki (Location: Jakarta) logs in, the policy filters the rows to show only ID-region data.
• If Sarah (Location: London) logs in, the same policy shows her UK-region data.

Why I'm Implementing This

The biggest headache in IT administration is "Permission Creep"—users keeping access they no longer need because they changed departments but were never removed from their old LDAP groups.

By using ABAC, the security policy is tied to the current state of the user's profile. It’s cleaner, it’s more secure, and it’s significantly easier to audit during compliance season.