Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Mon, 8 Sep 2014 21:49:29 +0000 (UTC)
From: "Robert Levas (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12739906.1410194648000.20831.1410212969424@Atlassian.JIRA>
In-Reply-To: <JIRA.12739906.1410194648000@Atlassian.JIRA>
References: <JIRA.12739906.1410194648000@Atlassian.JIRA>
 <JIRA.12739906.1410194648128@arcas>
Subject: [jira] [Commented] (AMBARI-7204) Ambari Automated Kerberization
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Robert Levas commented on AMBARI-7204:
--------------------------------------

[~eronwright], thanks for your comments....  I will take them inconsideration while building this. 

Some comments on your comments....

{quote}
1. Support numerous cross-realm trusts. The cluster's home realm may require trust relationships with numerous other realms, both northward (trusted) and southward (trusting) of the cluster realm. For example, users from numerous AD realms may communicate with the cluster. The cluster may in turn communicate with numerous backend storage systems (each in an independent realm).
{quote}

I thought about this, however I could not seem to find a valid use case for any of these.  I could imagine in a large enterprise that there may be multiple AD realms, and setting up the (one-way)  cross-domain trusts for these will not be that difficult.  My guess is that initially Ambari will not support such a case but it should not be that hard to add it later, if deemed necessary. 

{quote}
2. Improve the organization of the KDC information within the plan. The terms 'managed' and 'unmanaged' appear to serve numerous purposes and are overloaded. For example, in the current schema, how would one define an unmanaged KDC for the cluster plus a trust relationship with another (umanaged) realm? The term 'unmanaged' cannot be used twice as a key. My suggestion is to provide three sections:
{quote}

I will need to re-read the document. I didn't notice this issue.  Essentially, there are two main cases with some sub-cases:
# Managed KDC
## Stand-alone
## Cross-domain trust with unmanaged KDC
# Unmanaged KDC
## KDC
## Active Directory

I hope this clears it up a bit.

{quote}
3. Forwardable tickets. Please ensure that any managed KDC is configured to generate forwardable tickets.
{quote}

This is the plan, thanks for pointing out that it wasn't clear in the design.

{quote}
4. Clarify whether 'trust' principals are automatically created in the 'unmanaged' cluster KDC scenario. I think it is clear that keytabs are created in every scenario. But the cross-realm trust principal for a given trust relationship, in what cases is it created by Ambari? My vote is, only in the managed scenario.
{quote}

It should be assumed that whether the KDC is managed or unmanaged, principals for the Hadoop services will be created by Ambari.  It think that it would be much easier if Ambari didn't have to create the principals in the unmanaged scenario; however that would defeat one of the purposes of this exercise which is to simplify he process of setting up Kerberos.   

{quote}
5. Provide a user extension point. For settings not contemplated in the proposal, perhaps the user may provide snippets to be included in krb5.conf.
{quote}

Let me think on this a while. I am not sure how "dangerous" it would be to let the user add their own configuration data to the krb5.conf file.  However maybe the user is more educated on Kerberos than I assume. :)


> 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)