[
https://issues.apache.org/jira/browse/AMBARI-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14148190#comment-14148190
]
Robert Levas commented on AMBARI-7204:
--------------------------------------
[~eronwright]
I believe that the configuration structure is rather flexible now - so your use
case should be supported. I will add it to the set of use cases when I get the
chance. I am sure that I will be updating the document as I discover more about
how Ambari and the API works.
As for the identity blocks, I though about the trust identity and had a setting
for that, but failed to include it. I will make sure I add that. What I was
planning was to add a "category" property for an identity. The categories
would be at least 'admin' and 'trust'. We will need to know the difference in
the case where we need to programmatically create principals on behalf of the
installed services and need to authenticate as an administrative user. This
structure may also be expanded once I get more into working with an Active
Directory and what properties are needed to create principals there. I suspect
that I will need some LDAP properties, at least a base DN.
Also, I am tossing around the idea of getting rid of the
cluster-env/kerberos_domain property. This value is currently in use, but I am
not sure why. If it is not needed once this is implemented, it will probably
go away. Other than that, your example looks good to me.
> 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
> Fix For: 2.0.0
>
> 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)
