Impala Impersonation Problem

[carlos...@gmail.com]

Hello,

Some weeks ago, we enabled Impala impersonations so everything was done as the logged-in user in Hue and everything worked fine.

However, we have test it again today and seems that the impersonation is not working anymore.

Nothing has change in the cluster (CDH 5.4.2 + Hue 3.7.0 + Impala 2.2.0):

The file hue.ini still has the line:

  # Turn on/off impersonation mechanism when talking to Impala
  impersonation_enabled=True

And Impala configuration throught Cloudera Manager still has the property:

authorized_proxy_user_config -> hue=*

We have tried to add this property too:

Impala Daemon Command Line Argument Advanced Configuration Snippet (Safety Valve) -> -authorized_proxy_user_config=hue=*

The query is too simple:

create table user.test (asdf VARCHAR);

but /user/hive/warehouse/user.db/test is always created by impala:hive.

Any idea?

Thank you so much.

[Romain Rigaux]

On the /desktop/dump_config page of Hue, bottom Impala section, do you see Impersonation to True there too?

Before creating the table, did you check that /user/hive/warehouse/user.db/test did not exist?

To unsubscribe from this group and stop receiving emails from it, send an email to hue-user+u...@cloudera.org.

[carlos...@gmail.com]

Yes, I can see impersonation_enabled to True on the /desktop/dump_config page of Hue

And the folder did not exist before creating the table (creating a new database generates the same problem).

The table under HDFS directory /user/hive/warehouse/... is always created by impala:hive.

Any advice? Thanks

[Romain Rigaux]

Indeed, I could repro it. Let me dig a bit with the Impala guys

[Romain Rigaux]

It seems like CM does not generate the --authorized_proxy_user_config=hue* into the Impalad. We opened a bug for that and the current workaround is to add this flag directly in the safety valve of the Impalad

[carlos...@gmail.com]

Hello Romain,

First of all, thank you for detect that and the time that you are spending on this problem.

However, I think that I had already tried the workaround you suggest in one of my multiple tests without any change in the impersonation:

And it seems that it is arriving to impalad_flags:

I have tried putting:

• authorized_proxy_user_config=hue* in Cloudera in order to recieve -authorized_proxy_user_config=hue* in impalad_flags.
• -authorized_proxy_user_config=hue* in Cloudera in order to recieve --authorized_proxy_user_config=hue* in impalad_flags.
• --authorized_proxy_user_config=hue* in Cloudera in order to recieve ---authorized_proxy_user_config=hue* in impalad_flags.
  

With first and second, table is still created by impala:hive so no change.

With the last one or if I clean the property i recieve an error. This indicate that proxy was well configured previously?

      User 'hue' is not authorized to delegate to 'usubanc4'. User delegation is disabled.

Am I doing something wrong?

Thanks, Carlos.

[Romain Rigaux]

So first two works, I could see the queries running as 'romain' on the /queries page of the impalad.

However indeed, the table is still created as 'impala', which make me thinks that Impala just does not impersonate anything in practice.

Asking them again

To unsubscribe from this group and stop receiving emails from it, send an email to hue-user+u...@cloudera.org.

[Romain Rigaux]

According to them, "this is by design"

[carlos...@gmail.com]

So Impala does not support impersonation. Is that?

We understand that it could be "more secure", but from our point of view this is a design problem:

An user can create a table from Impala and then he can't manage it from other services that really work with impersonation (like Hive or Oozie).

However, thanks for your time and the efforts you spent on this problem.

[Maila Zorzan]

@Romain Rigaux, I need to get the user's session. I need to pass this user name as a parameter.

Could you tell me... how can I identify the variable user? What is the name of variable user in HUE?

Thanks in advance!

Best regards,

Maila.