ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eron Wright (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-7204) Ambari Automated Kerberization
Date Mon, 08 Sep 2014 22:52:28 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126243#comment-14126243
] 

Eron Wright  commented on AMBARI-7204:
--------------------------------------

Let me give some background.  The company I work for provides a Kerberos-capable HCFS and
thus the 'trusting'  relationship (where a Kerberized Hadoop is a client to a Kerberized storage
backend) is important to us.    The common practice involves three Kerberos realms, a. the
user realm (typically AD-based), b. the Hadoop cluster realm, and c. the storage realm.  
 The krb5.conf on each node thus contains three realm entries.  

I think the initial version of the feature should support a list of realms (not fixed at two),
 to future-proof the 'plan' schema.  It is much easier to do now than later.

Whether or not the cluster's KDC is 'managed' (i.e. installed by Ambari onto a cluster node)
is orthogonal to other considerations, such as whether to generate keytabs and whether the
cluster node's krb5.conf need contain any additional realms.       My preferred design would
separate the following concerns:   a.  the krb5 configuration on the cluster nodes (realms,
domain mappings, etc.), b. service principals + keytabs, c. managed KDC.

To manage scope, I suggest you defer the 'managed KDC' feature, since enterprise readiness
(high-availability, backup, admin account management) are important unresolved issues.   I
think the most useful improvement at this time is (a) and (b) from above paragraph.

> Ambari Automated Kerberization
> ------------------------------
>
>                 Key: AMBARI-7204
>                 URL: https://issues.apache.org/jira/browse/AMBARI-7204
>             Project: Ambari
>          Issue Type: Epic
>          Components: ambari-server, security, stacks
>    Affects Versions: 2.0.0
>         Environment: Kerberos
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>              Labels: active-directory, authentication, kerberos, mit-kerberos, security,
stack
>         Attachments: AmbariClusterKerberization.pdf
>
>   Original Estimate: 2,016h
>  Remaining Estimate: 2,016h
>
> *Problem*
> Manually installing and setting up Kerberos for a secure Hadoop cluster is error prone,
largely manual and a potential source of configuration problems. It requires many steps where
configuration files and credentials may need to be distributed across many nodes.  Because
of this the process is time consuming and lead to a high probability of user error.
> The problem is exacerbated when the cluster is modified by adding or removing nodes and
services.
> *Solution*
> Use Ambari to secure the cluster using Kerberos.  By automating the process of setting
up Kerberos, the repetitive tasks of distributing configuration details and credentials can
be done in parallel to the nodes within the cluster.  This also negates most user-related
errors due to the lack of interaction a user has with the process.  
> See [^AmbariClusterKerberization.pdf] for more details.



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

Mime
View raw message