You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@impala.apache.org by Sailesh Mukil <sa...@cloudera.com> on 2017/07/11 06:01:58 UTC
Re: Using JDBC with Impala, Kerberos and Sentry
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 <rh...@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
Re: Using JDBC with Impala, Kerberos and Sentry
Posted by Russell Harlin <rh...@gmail.com>.
Hi Sailesh,
I meant the client principal, i.e. whatever I kinit-ed with.
From what I can tell, the Hive JDBC driver doesn't have the KrbServiceName
or other Krb* parameters or equivalents. I might be missing something, but
presumably that must be why the Hive JDBC driver has that requirement that
it use the 'impala' principal and the Cloudera JDBC driver does not.
Thanks for your help.
-Russell
On Wed, Jul 12, 2017 at 10:25 AM, Sailesh Mukil <sa...@cloudera.com>
wrote:
> > "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 <rh...@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/docum
>> entation/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 <sa...@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/impa
>>> la-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 <rh...@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
>>>
>>
>>
>
Re: Using JDBC with Impala, Kerberos and Sentry
Posted by Sailesh Mukil <sa...@cloudera.com>.
> "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 <rh...@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 <sa...@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 <rh...@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
>>
>
>
Re: Using JDBC with Impala, Kerberos and Sentry
Posted by Russell Harlin <rh...@gmail.com>.
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 <sa...@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 <rh...@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
>