Support Questions
Find answers, ask questions, and share your expertise

Ranger implementation - Hive impersonation false

Solved Go to solution
Highlighted

Ranger implementation - Hive impersonation false

Rising Star

Customer wants Hive column level ACLs to be set up in Ranger, so we suggested to set Hive doAs property to 'false' to impersonate as hive user and set Hive Column level ACLs in ranger. In this case all the jobs will be shown as to run as 'hive' user in Resource manager. At the same time, customer wants to know the resource utilization at the user level. Which is not possible because all the jobs will be run as hive user. Is there a way out to satisfy customer's requirement ? Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Re: Ranger implementation - Hive impersonation false

Set enable.doAs to "False"...This is really good explanation Link

When set to "false," the Hive user identity is used instead of the individual user identities for YARN. This setting enhances security and reuse:

hive.server2.enable.doAs=false

Note When doAs is set to false, queries execute as the Hive user and not the end user. When multiple queries run as the Hive user, they can share resources. Otherwise, YARN does not allow resources to be shared across different users. When the Hive user executes all of the queries, a Tez session opened for one query and is holding onto resources can use those resources for the next query without re-allocation.

View solution in original post

5 REPLIES 5
Highlighted

Re: Ranger implementation - Hive impersonation false

Set enable.doAs to "False"...This is really good explanation Link

When set to "false," the Hive user identity is used instead of the individual user identities for YARN. This setting enhances security and reuse:

hive.server2.enable.doAs=false

Note When doAs is set to false, queries execute as the Hive user and not the end user. When multiple queries run as the Hive user, they can share resources. Otherwise, YARN does not allow resources to be shared across different users. When the Hive user executes all of the queries, a Tez session opened for one query and is holding onto resources can use those resources for the next query without re-allocation.

View solution in original post

Highlighted

Re: Ranger implementation - Hive impersonation false

Rising Star

In that case, if the admin wants to see how much resources (lets say number of containers & vcores) used by a particular user 'user1', how can he get those statistics ?

Highlighted

Re: Ranger implementation - Hive impersonation false

This is applicable to Hive only. Non-Hive/Yarn jobs will be coming from users running the job.

@hrongali@hortonworks.com

Re: Ranger implementation - Hive impersonation false

Rising Star

@Neeraj Sabharwal, I'm a bit confused on this impersonation concept. I understand the resource reuse benefits part. But, if I have different users running Hive queries and they all run as the "hive" user, then what is to prevent one user's "insert overwrite directory "some_relative_dir" select from ...." results from overwriting some other users query that just happens to pick the same directory path? If a relative path is supplied, then Hive will write the results to "/user/hive/some_relative_dir".

I tried to read the best practices link at the end of this post but the page is not loading.

Highlighted

Re: Ranger implementation - Hive impersonation false

Rising Star