Ramesh, thanks.
Alex, it seems you are confusing between the Plugin Interface and the Ranger
API (isAccessAllowed()).
For HAWQ, you will be implementing the Plugin Interface (akin
RangerKafkaAuthorizer) and in that plugin you will (or could) use Hadoop Common
to get the groups for the
Alex,
What I was mentioning when you do plugin.isAccessAllowed(request), your
request should contain both user / group and to get the group information
you can use Hadoop UserGroupInformation API.
That is what Don Bosco Durai was mention in this last email.
Additional comments I have put
Alex
Both Abhay and Ramesh are correct. In the Hadoop eco-system we want to ensure
that the users and groups are consistent across all components. And generally,
AD/LDAP or Unix system user/groups are the source of truth.
>>This also means user <--> group mapping in Ranger is NOT the
Adding to Abhay comment,
In most of the Ranger Plugin from the components side we use
org.apache.hadoop.security.UserGroupInformation API
https://hadoop.apache.org/docs/r1.0.4/api/org/apache/hadoop/security/UserGr
oupInformation.html which will wrap around JAAS and provides the mechanism
to
Hi Alex,
This is exactly right. Users, groups and their associations in Ranger
(specifically Ranger Admin) are props for being able to define policies.
They are not the Œsource of truth¹. It is expected that the correct user
<‹-> group associations will be available in the component (service)
Hi Ranger experts,
We are developing a custom Ranger Plugin for Apache HAWQ(incubating) and
noticed that group policies are not behaving as we expected.
In Ranger, we define a user U (actually synched from OS). We then manually
define group G and enroll user U into it. We then define a policy