You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Sandor Magyari (JIRA)" <ji...@apache.org> on 2016/03/24 17:01:25 UTC

[jira] [Created] (AMBARI-15561) Automate creation of Ambari Server proxy users (secure/non-secure clusters), principal and keytab, setup of JAAS (secure clusters)

Sandor Magyari created AMBARI-15561:
---------------------------------------

             Summary: Automate creation of Ambari Server proxy users (secure/non-secure clusters), principal and keytab, setup of JAAS (secure clusters)
                 Key: AMBARI-15561
                 URL: https://issues.apache.org/jira/browse/AMBARI-15561
             Project: Ambari
          Issue Type: Improvement
          Components: ambari-server
            Reporter: Sandor Magyari
            Assignee: Sandor Magyari
            Priority: Critical
             Fix For: ambari-2.4.0


When cluster is Kerberos-enabled, certain cluster components (such as Storm Nimbus server) by default require SPNEGO authentication. Additionally, other components (such as the NameNode UI, and ResourceManager UI) can be configured for SPNEGO authentication. For Ambari Server to talk with these components, Ambari Server needs to have a principal and keytab available.

This is also needed for Ambari Views (where Ambari Server proxies requests for view REST calls) to a kerberos-enabled cluster.

Currently, the setup of Ambari Server for Kerberos is a manual step, documented here:

http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html

The creation and setup of the Ambari Server principal + keytab should be automated when a user configures Kerberos using the Ambari wizard.

The manual option will still have to exist (for cases where Ambari Server is running in standalone mode) but when Ambari is managing a cluster + enables Kerberos, automating this step will save the operator from having to do it outside of the Ambari wizard.

In a scenario where multiple Ambari servers are managing a single cluster, only the _operation master_ Ambari server will be affected.  All other Ambari server instances will need to be manually updated.  Meaning, the Ambari server keytab file will need to be manually distributed to the _other_ Ambari server hosts.  Also, the _other_ Ambari servers' JAAS files will need to be manually updated either by editing the {{/etc/ambari-server/conf/krb5JAASLogin.conf}} file or by executing {{ambari-server setup-security}} and selecting option #3, {{Setup Ambari kerberos JAAS configuration}}.

When generating the principal name for the Ambari server's Kerberos identity, it's naming pattern is to be taken from the Kerberos descriptor where its default value is to include the cluster's name.  The user should be able the change this pattern if desired. When Ambari is able to manage multiple clusters, this may need to change.  Until then the default value should be: 
{code}
ambari-server-${cluster_name}@${realm}
{code}

During the process of enabling Kerberos, the user should be able to select whether or not the Ambari server's Kerberos Identity is to be automatically generated and configured. The default value is to enable this feature.  Which not only creates the Kerberos identity and updates the JAAS configuration file; but add the necessary proxy user configurations to the {{core-site}} configuration. For example:

{code}
"hadoop.proxyuser.${ambari-server.user}.hosts": "*",
"hadoop.proxyuser.${ambari-server.user}.groups": "*"
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)