Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

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

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.

5 REPLIES 5

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.

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 ?

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.

Re: Ranger implementation - Hive impersonation false

Rising Star
Don't have an account?
Coming from Hortonworks? Activate your account here