[
https://issues.apache.org/jira/browse/NIFI-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192450#comment-15192450
]
Bryan Bende commented on NIFI-1488:
-----------------------------------
Did some more investigating this morning... The reason I was getting the
exception was because UserGroupInformation.isSecurityEnabled() was evaluating
to false due to me only providing hbase-site.xml as a configuration file, and
even though my hbase-site.xml had kerberos enabled, the isSecurityEnabled()
method works off of the Hadoop core-site.xml. After adding core-site.xml to the
list of config files it does appear to be working now.
After learning a lot more than I planned to about Kerberos, I still have some
questions/concerns though...
1) Based on the above, is it expected behavior that the user has to know to
provide both hbase-site.xml and core-site.xml when using Kerberos, but can only
provide hbase-site.xml when not using Kerberos?
I was looking at HBase code and they appear to have a User class which
specifically checks if Kerberos is configured for HBase and I am wondering if
that might be appropriate here:
https://github.com/apache/hbase/blob/master/hbase-common/src/main/java/org/apache/hadoop/hbase/security/User.java#L249
2) I'm also wondering about the use of the static calls to
UserGroupInformation... does this work if you wanted to have two different
HBaseClientService instances talking to two different HBase clusters with
different principals/keytabs? also what if you have PutHDFS processors with
Kerberos, they also make these static calls, does that interfere here?
It seems like we might want to consider using the
"loginUserFromKeytabAndReturnUGI" which does not modify static state in UGI and
returns a reference to a UGI. From there we can perform operations using that
UGI through the doAs(...) method. I took a first pass at implementing this, but
needs a lot of work to clean it up:
https://github.com/bbende/nifi/blob/NIFI-1488/nifi-nar-bundles/nifi-standard-services/nifi-hbase_1_1_2-client-service-bundle/nifi-hbase_1_1_2-client-service/src/main/java/org/apache/nifi/hbase/HBase_1_1_2_ClientService.java#L232
3) The last thing which I mentioned in a previous comment is about the
validation, it seems like we would want consistent experience between the HDFS
processors and the HBaseClientService in terms of validating the principal and
keytab. I took a stab at refactoring the properties and validation from
AbstractHadoopProcessor into a common class, which would resolve the issue
Randy reported about not being able to use a '-' in the principal name, but I'd
still like to come up with a way to get rid of the non-final static reference
to NiFiProperties:
https://github.com/bbende/nifi/blob/NIFI-1488/nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/KerberosProperties.java
Depending how people feel about the above questions/concerns, I can keep going
with this tomorrow.
> Add Kerberos Support to HBase processors
> ----------------------------------------
>
> Key: NIFI-1488
> URL: https://issues.apache.org/jira/browse/NIFI-1488
> Project: Apache NiFi
> Issue Type: Improvement
> Affects Versions: 0.4.0, 0.4.1
> Reporter: Bryan Bende
> Assignee: Ricky Saltzer
> Fix For: 0.6.0
>
> Attachments:
> 0001-NIFI-1488-Adjusting-unused-imports-and-adding-licens.patch
>
>
> Our current HBase integration does not support communicating with a
> Kerberized HBase install. We should support this just like we do for the HDFS
> processors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
