Can CDH5.3 Sentry work without Kerberos?

[#1]

I am trying to evaluate Sentry in the CDH5.3 virtual machine provided by Cloudera.  Unfortunately I am having a lot of problems getting it to even work and I throught I'd check that my assumption that I can even get it to work is correct.

In this ( http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_sg_sentry_service.ht... ) documentation the prereqisites say:

• CDH 5.1.x (or later) managed by Cloudera Manager 5.1.x (or later). See the Cloudera Manager Administration Guide and Cloudera Installation and Upgrade for instructions.
• HiveServer2 and the Hive Metastore running with strong authentication. For HiveServer2, strong authentication is either Kerberos or LDAP. For the Hive Metastore, only Kerberos is considered strong authentication (to override, see Securing the Hive Metastore).
• Impala 1.4.0 (or later) running with strong authentication. With Impala, either Kerberos or LDAP can be configured to achieve strong authentication.
• Implement Kerberos authentication on your cluster. For instructions, see Enabling Kerberos Authentication Using the Wizard

I don't have kerberos or LDAP (since I'm in the virtual machine) so I override the HiveServer2/Hive Metastore requirement for strong authentication.

The last prerequisite says I need to implement Kerberos authentication.  Is this only if I want Impala to work; or will it stop Sentry from working entirely.

Thanks

Ty

[#2]

Thanks for the link to your kerberos bootstrap'er.  It seems to work for me.  Unfortunately I ran into a secondary problem and I'm not sure how to let Cloudera know about it.

On a clean CDH5.3 virtual machine I started Cloudera Manager and then ran your kerberos bootstrapper.  Then I ran the Kerberos configuration wizard in Cloudera Manager.  The restart failed to complete successfully.  It seemed like the Yarn NameNode was having trouble with the topology.map amd container-executer.cfg file permissions in the /var/run/cloudera-scm-agent/process/??-yarn-NODEMANAGER/ directory (note: ?? is a number generated each time I tried to restart the NodeManager).

On further inspection, and a couple snapshot reverts, I think I found the real problem.  the /etc and /etc/hadoop directories have group write permissions set.  This was identified in the NodeManager logs.  I started again and changed the permissions to remove the group write permission on both directories - before running the Cloudera Manager Kerberos configuration wizard.  This time it seems to have worked.  note: I hve not yet had a chance to test kerberos actually doing anything from a hdfs/hive/pig user perspective.

Only one last glitch in the system.  It looks like Spark does not have Kerberos credentials created for it.  The Spark History Server is showing as critical health and its log is identifying missing Kerberos credentials.  When I look at the Kerberos Credentials screen in Cloudera Manager I see credentials for all the services excpt Spark.  I'm not doing anything with Spark and I don't know anything about it so I'll just stop the service for now.

I am not sure if changing the directory permissions on /etc and /etc/hadoop will adversely affect other functions; but I hope my little investigation can help others.

[#3]

Thanks for the information!
Hmm, I have never met such kinds of problem, but I don't think the change
you did will break the other finctionalities.

Daisuke

[#4]

Usually /etc/ and /etc/hadoop don't have group write permissions. Not sure how they got there, but removing it seems like a good idea.