impala-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sailesh Mukil <sail...@cloudera.com>
Subject Re: Using JDBC with Impala, Kerberos and Sentry
Date Wed, 12 Jul 2017 17:25:01 GMT
> "When using the Cloudera driver does it successfully connect with other
principals?"

Do you mean 'KrbServiceName' ? Or do you mean the client principal, i.e.
whatever you kinit-ed with?

With the Cloudera JDBC driver, kinit-ing with a non-impala principal:
kinit systest

and using the following jdbc string works fine for me:
jdbc:impala://[HOST]:21050;AuthMech=1;KrbRealm=[REALM];KrbHostFQDN=[HOSTFQDN];KrbServiceName=impala;KrbAuthType=1

Looking at the logs of [HOST], I see the following:

I0710 22:36:23.381333 16462 authentication.cc:459] Successfully
authenticated client user "systest@[REALM]"
So, it does work with other client principals than 'impala'.

Unfortunately, I've not used the Hive JDBC driver, so I don't have the
required knowledge to comment on that.




On Tue, Jul 11, 2017 at 4:03 PM, Russell Harlin <rharlin@gmail.com> wrote:

> Hi Sailesh,
>
> Thanks, for the response.
>
> Just for reference, I'm actually using the Hive JDBC driver, rather than
> the Cloudera JDBC driver.  As you mentioned, I've been able to get it to
> attempt with different credentials by running kinit before my application.
> The issue that I'm having is that if I use any principal other than the one
> the impalad daemon was started with, it won't successfully connect.  I get
> a Kerberos auth error.  I'm guessing this is a known limitation, as it
> mentions the following in the docs with respect to the krb principal used
> for the JDBC connection: "The principal must be the same user principal you
> used when starting Impala." (From: https://www.cloudera.com/
> documentation/enterprise/5-10-x/topics/impala_jdbc.html#jdbc_connect).  I
> did just notice that this limitation is only in the "Using the Hive JDBC
> Driver" section and not the "Using the Cloudera JDBC Connector" section.
> Perhaps this this only a limitation for the Hive JDBC driver?  When using
> the Cloudera driver does it successfully connect with other principals?
>
> Thanks again,
>
> Russell
>
> On Mon, Jul 10, 2017 at 11:01 PM, Sailesh Mukil <sailesh@cloudera.com>
> wrote:
>
>> Hi Russell,
>>
>> Did you happen to look at the 'KrbAuthType' from Page 86 in the docs?
>> https://www.cloudera.com/documentation/other/connectors/
>> impala-jdbc/latest/Cloudera-JDBC-Driver-for-Impala-Install-Guide.pdf
>>
>> If you don't specify the KrbAuthType, it would look for the principal
>> in the following order (pasting from the doc):
>>
>> 1. First, the driver tries to obtain the Subject from the current
>> thread's inherited AccessControlContext. If the AccessControlContext
>> contains multiple Subjects, the driver uses the most recent Subject.
>>
>> 2. If the first method does not work, then the driver checks the
>> java.security.auth.login.config system property for a JAAS
>> configuration. If a JAAS configuration is specified, the driver uses
>> that information to create a LoginContext and then uses the Subject
>> associated with it.
>>
>> 3. If the second method does not work, then the driver checks the
>> KRB5_CONFIG and KRB5CCNAME system environment variables for a Kerberos
>> ticket cache. The driver uses the information from the cache to create
>> a LoginContext and then uses the Subject associated with it.
>>
>>
>> In the default case, when you don't have a JAAS conf file, I've
>> noticed that it picks the last kinit-ed user from the kerberos
>> credential cache (step 3) and uses that as the client principal (i.e.
>> the principal you're connecting as). Note that the 'KrbServiceName' is
>> the service principal name of the Impala server and not of the client.
>>
>> Eg:
>>
>> kinit foo
>> <Run JDBC app>
>>
>> In the above case, 'foo' will be used as the client principal and will
>> be used against all the Sentry authorization checks.
>>
>>
>> On Wed, Jun 21, 2017 at 10:04 AM, Russell Harlin <rharlin@gmail.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > Based on the Impala documentation, it seems like it's required that
>> JDBC connections use the same Kerberos principal used to start the impalad
>> daemon.  This seems to work fine for me.  My questions is, though, if I
>> also want to use Sentry authorization how does impala distinguish users,
>> since they're all using the same Kerberos principal?  Do we have to pass in
>> the desired user to the JDBC connection?  Does this mean that we have to
>> enable AD as well or can we use local users?
>> >
>> > Thanks,
>> >
>> > Russell
>>
>
>

Mime
View raw message