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 18:37:28 GMT

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

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

Some review comments:

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

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: 

    a. "cluster", defining the KDC for the Hadoop cluster itself, with either a 'managed'
or 'unmanaged' section within.
    b. "trusted", defining a +list+ of realms that are to be trusted, each with a 'trust_password'
(if the cluster KDC is managed).
    c. "trusting", defining a +list+ of realms that are to be trusting, each with a 'trust_password'
(if the cluster KDC is managed).

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

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.

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.   


> 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