ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandor Magyari (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-15561) Automate creation of Ambari Server proxy users (secure/non-secure clusters), principal and keytab, setup of JAAS (secure clusters)
Date Thu, 24 Mar 2016 21:21:25 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-15561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sandor Magyari updated AMBARI-15561:
------------------------------------
    Description: 
The aim of this improvement is to automate the following:

- creation of proxy users for Ambari server necessary for views (Files, Hive, Pig, Tez etc)
- creation of Ambari Server principal and keytab, and setup of JAAS which is currently a manual
step documented here:

http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html

In case of a non secure cluster, Ambari proxy user will be set up for the user account Ambari
Server is running as. This is specified in *ambari-server.properties* by *ambari-server.user*
and can be adjusted by running 'ambari-server setup'.
Stackadvisor is responsible for configuring proxy users, both for secure / non-secure cluster,
wizard or blueprint based deployments.
Therefore in case of blueprint based deployments proxy users will be only created if "config_recommendation_strategy":
"ALWAYS_APPLY" in Cluster template.
The following proxy users will be configured by stackadvisor:

{code}
hadoop.proxyuser.${ambari_proxy_user}.groups=*
hadoop.proxyuser.${ambari_proxy_user}.hosts=*

hadoop.proxyuser.hcat.groups=*
hadoop.proxyuser.hcat.hosts=*

webhcat.proxyuser.${ambari_proxy_user}.groups=*
webhcat.proxyuser.${ambari_proxy_user}.hosts=*

yarn.timeline-service.http-authentication.proxyuser.${ambari_proxy_user}.hosts=*
yarn.timeline-service.http-authentication.proxyuser.${ambari_proxy_user}.users=*
yarn.timeline-service.http-authentication.proxyuser.${ambari_proxy_user}.groups=*
{code}

For a secure (eg. securityType=KERBEROS) cluster proxy user will be setup based on Ambari
Server principal.
A new identity 'ambari-server' will be added to default kerberos descriptor where principal
name is specified which can be modified either in Kerberos Setup wizard screen, or by submitting
a custom kerberos descriptor in Blueprint case.
By default principal name is:
{code}
ambari-server-${cluster_name}@${realm}
{code}

Generation of Ambari Server principal and keytab can be enabled / disabled by setting config
property *create_ambari_principal* = true / false in kerberos-env config. ('Create Ambari
Principal & Keytab' on Keberos Setup wizard screen).

In a scenario where multiple Ambari servers are managing a single cluster, only the _operation
master_ Ambari server will be affected.  All other Ambari server instances will need to be
manually updated.  Meaning, the Ambari server keytab file will need to be manually distributed
to the _other_ Ambari server hosts.  Also, the _other_ Ambari servers' JAAS files will need
to be manually updated either by editing the {{/etc/ambari-server/conf/krb5JAASLogin.conf}}
file or by executing {{ambari-server setup-security}} and selecting option #3, {{Setup Ambari
kerberos JAAS configuration}}.

  was:
The aim of this improvement is to automate the following:

- creation of proxy users for Ambari server necessary for views (Files, Hive, Pig, Tez etc)
- creation of Ambari Server principal and keytab, and setup of JAAS 

In case of a non secure cluster, Ambari proxy user will be set up for the user account Ambari
Server is running as. This is specified in *ambari-server.properties* by *ambari-server.user*
and can be adjusted by running 'ambari-server setup'.
The following proxy users will be configured by stackadvisor:

{code}
hadoop.proxyuser.${ambari principal name}.groups=*
hadoop.proxyuser.${ambari principal name}.hosts=*

hadoop.proxyuser.hcat.groups=*
hadoop.proxyuser.hcat.hosts=*

webhcat.proxyuser.${ambari principal name}.groups=*
webhcat.proxyuser.${ambari principal name}.hosts=*

yarn.timeline-service.http-authentication.proxyuser.${ambari principal name}.hosts=*
yarn.timeline-service.http-authentication.proxyuser.${ambari principal name}.users=*
yarn.timeline-service.http-authentication.proxyuser.${ambari principal name}.groups=*
{code}

Stackadvisor is responsible for configuring proxy users, both for secure / non-secure cluster,
wizard or blueprint based deployments.

For a secure (eg. securityType=KERBEROS) cluster proxy user will be setup based on Ambari
Server principal.
Principal name is specified in default kerberos-descriptor and can be modified either in Kerberos
Setup wizard screen, or by submitting a custom kerberos descriptor in Blueprint case.
Generation of Ambari Server principal and keytab can be enabled / disbaled by setting config
property *create_ambari_principal* = true / false in kerberos-env config. ('Create Ambari
Principal & Keytab' on Keberos Setup wizard screen)

When cluster is Kerberos-enabled, certain cluster components (such as Storm Nimbus server)
by default require SPNEGO authentication. Additionally, other components (such as the NameNode
UI, and ResourceManager UI) can be configured for SPNEGO authentication. For Ambari Server
to talk with these components, Ambari Server needs to have a principal and keytab available.

This is also needed for Ambari Views (where Ambari Server proxies requests for view REST calls)
to a kerberos-enabled cluster.

Currently, the setup of Ambari Server for Kerberos is a manual step, documented here:

http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html

The creation and setup of the Ambari Server principal + keytab should be automated when a
user configures Kerberos using the Ambari wizard.

The manual option will still have to exist (for cases where Ambari Server is running in standalone
mode) but when Ambari is managing a cluster + enables Kerberos, automating this step will
save the operator from having to do it outside of the Ambari wizard.

In a scenario where multiple Ambari servers are managing a single cluster, only the _operation
master_ Ambari server will be affected.  All other Ambari server instances will need to be
manually updated.  Meaning, the Ambari server keytab file will need to be manually distributed
to the _other_ Ambari server hosts.  Also, the _other_ Ambari servers' JAAS files will need
to be manually updated either by editing the {{/etc/ambari-server/conf/krb5JAASLogin.conf}}
file or by executing {{ambari-server setup-security}} and selecting option #3, {{Setup Ambari
kerberos JAAS configuration}}.

When generating the principal name for the Ambari server's Kerberos identity, it's naming
pattern is to be taken from the Kerberos descriptor where its default value is to include
the cluster's name.  The user should be able the change this pattern if desired. When Ambari
is able to manage multiple clusters, this may need to change.  Until then the default value
should be: 
{code}
ambari-server-${cluster_name}@${realm}
{code}

During the process of enabling Kerberos, the user should be able to select whether or not
the Ambari server's Kerberos Identity is to be automatically generated and configured. The
default value is to enable this feature.  Which not only creates the Kerberos identity and
updates the JAAS configuration file; but add the necessary proxy user configurations to the
{{core-site}} configuration. For example:

{code}
"hadoop.proxyuser.${ambari-server.user}.hosts": "*",
"hadoop.proxyuser.${ambari-server.user}.groups": "*"
{code}


> Automate creation of Ambari Server proxy users (secure/non-secure clusters), principal
and keytab, setup of JAAS (secure clusters)
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMBARI-15561
>                 URL: https://issues.apache.org/jira/browse/AMBARI-15561
>             Project: Ambari
>          Issue Type: Improvement
>          Components: ambari-server
>            Reporter: Sandor Magyari
>            Assignee: Sandor Magyari
>            Priority: Critical
>             Fix For: ambari-2.4.0
>
>
> The aim of this improvement is to automate the following:
> - creation of proxy users for Ambari server necessary for views (Files, Hive, Pig, Tez
etc)
> - creation of Ambari Server principal and keytab, and setup of JAAS which is currently
a manual step documented here:
> http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html
> In case of a non secure cluster, Ambari proxy user will be set up for the user account
Ambari Server is running as. This is specified in *ambari-server.properties* by *ambari-server.user*
and can be adjusted by running 'ambari-server setup'.
> Stackadvisor is responsible for configuring proxy users, both for secure / non-secure
cluster, wizard or blueprint based deployments.
> Therefore in case of blueprint based deployments proxy users will be only created if
"config_recommendation_strategy": "ALWAYS_APPLY" in Cluster template.
> The following proxy users will be configured by stackadvisor:
> {code}
> hadoop.proxyuser.${ambari_proxy_user}.groups=*
> hadoop.proxyuser.${ambari_proxy_user}.hosts=*
> hadoop.proxyuser.hcat.groups=*
> hadoop.proxyuser.hcat.hosts=*
> webhcat.proxyuser.${ambari_proxy_user}.groups=*
> webhcat.proxyuser.${ambari_proxy_user}.hosts=*
> yarn.timeline-service.http-authentication.proxyuser.${ambari_proxy_user}.hosts=*
> yarn.timeline-service.http-authentication.proxyuser.${ambari_proxy_user}.users=*
> yarn.timeline-service.http-authentication.proxyuser.${ambari_proxy_user}.groups=*
> {code}
> For a secure (eg. securityType=KERBEROS) cluster proxy user will be setup based on Ambari
Server principal.
> A new identity 'ambari-server' will be added to default kerberos descriptor where principal
name is specified which can be modified either in Kerberos Setup wizard screen, or by submitting
a custom kerberos descriptor in Blueprint case.
> By default principal name is:
> {code}
> ambari-server-${cluster_name}@${realm}
> {code}
> Generation of Ambari Server principal and keytab can be enabled / disabled by setting
config property *create_ambari_principal* = true / false in kerberos-env config. ('Create
Ambari Principal & Keytab' on Keberos Setup wizard screen).
> In a scenario where multiple Ambari servers are managing a single cluster, only the _operation
master_ Ambari server will be affected.  All other Ambari server instances will need to be
manually updated.  Meaning, the Ambari server keytab file will need to be manually distributed
to the _other_ Ambari server hosts.  Also, the _other_ Ambari servers' JAAS files will need
to be manually updated either by editing the {{/etc/ambari-server/conf/krb5JAASLogin.conf}}
file or by executing {{ambari-server setup-security}} and selecting option #3, {{Setup Ambari
kerberos JAAS configuration}}.



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

Mime
View raw message