CDESS study materials
CDESS study resources

Ranger Masking Bypassed by a Public Sandbox Policy

CDESS · Put your knowledge to work in context.

All case studies

Ranger Masking Bypassed by a Public Sandbox Policy

A CDP Private Cloud Base cluster with 240 nodes uses Active Directory over LDAP for users and groups, Kerberos for authentication, and Ranger for authorization. The AD group fin_analysts is nested inside finance_all. A Ranger Hive policy grants finance_all SELECT on finance.transactions with column masking on ssn and a row filter region='US'. A second policy grants public SELECT on the same table with no masking, created for a sandbox. Analysts report seeing full SSNs in Hive and Impala; Ranger audit shows access allowed by the public policy. The HDFS directory has a Ranger HDFS policy allowing public read, and an HDFS ACL grants fin_analysts read. Ranger usersync runs every 60 minutes with AD group nesting enabled. The security team wants least privilege, no break for the sandbox, and proof that masking applies.

1. Why is masking not applied, and how would you correct the Ranger policies without breaking the sandbox?

Read the worked answer

Masking is not a table-wide switch; it is enforced by the policy that grants the column access. The public SELECT policy grants the table without a mask, and the audit confirms that this is the effective grant. The finance_all policy may also exist, but a broad allow without masking can make the unmasked column visible. Treat the public grant as the root cause, not the masking configuration on the other policy.

Remove public from finance.transactions. Create a sandbox view that exposes only permitted columns, or exposes ssn with a mask, and grant public SELECT on that view instead of the base table. Keep finance_all on the base table with masking and the region row filter. If sandbox users need row-level restrictions, put them in the view as well. Use tag-based masking for ssn only after verifying how your Ranger version combines multiple policies. Test with a real fin_analysts account and a sandbox account in both Hive and Impala; Impala may need metadata invalidation before the new grants take effect.

2. What is the risk of the HDFS ACL and Ranger HDFS policy, and how do you prove masking is effective end to end?

Read the worked answer

The HDFS ACL and the Ranger HDFS public-read policy create a second access path to the underlying files. Hive and Impala masking protects SQL access, but a user who can read the directory directly can bypass the masking entirely. Remove the public HDFS policy and the broad ACL, then grant HDFS access only to the service principals and groups that need it. Do not rely on HDFS ACLs to grant analyst access when Ranger Hive is the intended control plane.

Prove effectiveness with negative and positive tests. As a fin_analysts user, query the base table and verify that ssn is masked and only region='US' rows return. As a sandbox user, query the view and confirm that only allowed columns are visible. Try direct hdfs dfs access as both users and confirm it is denied. Check Ranger audit for the policy that allowed each request, and inspect usersync logs to confirm nested group membership is resolved. Repeat after a usersync cycle so you are not testing stale group data.