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