Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 15 Oct 2015 18:01:05 +0000 (UTC)
From: "Sandor Magyari (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12905181.1444912420000.50307.1444932065090@Atlassian.JIRA>
In-Reply-To: <JIRA.12905181.1444912420000@Atlassian.JIRA>
References: <JIRA.12905181.1444912420000@Atlassian.JIRA>
 <JIRA.12905181.1444912420338@arcas>
Subject: [jira] [Updated] (AMBARI-13431) Blueprints: Configuration to select
 Kerberos
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/AMBARI-13431?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sandor Magyari updated AMBARI-13431:
------------------------------------
    Attachment:     (was: AMBARI-13431.patch)

> Blueprints: Configuration to select Kerberos
> --------------------------------------------
>
>                 Key: AMBARI-13431
>                 URL: https://issues.apache.org/jira/browse/AMBARI-13431
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>            Reporter: Sandor Magyari
>            Assignee: Sandor Magyari
>             Fix For: 2.1.3
>
>
> This task tracks the required changes in the handling code for the Bluepr=
int .json and the Cluster Creation Template .json files in order to allow t=
he user to request that a given cluster be Kerberized. =20
> The most natural place for this configuration will likely be in the Clust=
er Creation template, which would then allow a given Blueprint to be refere=
nced via secure and non-secure cluster creation requests.=20
> Based on feedback from Product Management, a customer should be able to i=
ndicate that a cluster is to be Kerberized in either the Blueprint .json or=
 the Cluster Creation template .json.=20
> This feature should support enabling Kerberos at the level of the Bluepri=
nt or the Cluster Creation template.  In either JSON document, the user sho=
uld be able to indicate a security tag that looks like:
> {code}
> "security" : {
>     "type" : "KERBEROS",
>     "kerberos_descriptor_reference" : "kd1",
>     "kerberos_descriptor" : {
>        ...
>     }
>   }
> {code}
> The "type" field in the new "security" map should be set to "KERBEROS" in=
 order to indicate that Kerberos should be supported. =20
> The "kerberos_descriptor_reference" field in the "security" map could be =
used to refer to an existing Kerberos descriptor that has been POST-ed to t=
he Ambari REST API. =20
> If the user wishes to embed the Kerberos descriptor in the Blueprint or C=
luster Creation template, then the "kerberos_descriptor" field in the "secu=
rity" map should be set to the contents of that descriptor. =20
> The "security" map could eventually also include other configuration item=
s pertaining to the security of a given cluster.  While Kerberos is the ini=
tial support being added, other security mechanisms may evolve over time, a=
nd we should be able to use the same configuration structures in order to e=
ventually integrate with these technologies as well. =20
> *Note: The user should typically only specify a "kerberos_descriptor_refe=
rence" or a "kerberos_descriptor".  If both are set, the Blueprint processo=
r should treat this as an error condition.*
> This new JSON element should exist at the top-level of the Cluster Creati=
on Template and Blueprint documents. =20
> The following example shows what a Cluster Creation template might look l=
ike in this scenario:
> {code}
> {
>   "blueprint" : "blueprint-ha",
>   "default_password" : "default",
>   "security" : {
>     "type" : "KERBEROS",
>     "kerberos_descriptor_reference" : "kd1",
>     "kerberos_descriptor" : {
>        ...
>     }
>   },
>   "host_groups" :[
>     {
>       "name" : "host_group_1",=20
>       "hosts" : [        =20
>         {
>           "fqdn" : "c6401.ambari.apache.org"
>         }
>       ]
>     },
>    ...=20
> ]
> }
> {code}
> The following example shows what a Blueprint that requires Kerberos suppo=
rt should look like:
> {code}
> {
>   "host_groups": [
>     {
>       "name": "master",
>       "configurations": [
>        ...
>       ],
>       "components": [
>         {
>           "name": "NAMENODE"
>         },
>         {
>           "name": "SECONDARY_NAMENODE"
>         },
>         {
>           "name": "RESOURCEMANAGER"
>         },
>         {
>           "name": "HISTORYSERVER"
>         },
>         {
>           "name": "APP_TIMELINE_SERVER"
>         },
>         {
>           "name": "ZOOKEEPER_SERVER"
>         }
>       ],
>       "cardinality": "1"
>     },
>     ...
>   ],
>   "Blueprints": {
>     "blueprint_name": "multi-simple-yarn",
>     "stack_name": "HDP",
>     "stack_version": "2.2",
>     "security" : {
>     "type" : "KERBEROS",
>     "kerberos_descriptor_reference" : "kd1",
>     "kerberos_descriptor" : {
>        ...
>        }
>      }
>   }
> }
> {code}
> In the example above, the "type" field is included in the "security" map =
section of the Blueprint document, embedded within the "Blueprints" map.  T=
his is the most natural place for the Blueprint itself, since it contains t=
he metadata that should be associated with the Blueprint deployment, outsid=
e of the configuration and components.=20
> h2. Priority Ordering
> Since the Kerberos setting will be supported in either the Blueprint or t=
he Cluster Creation template, this new support will need to handle the case=
s where the setting is chosen in both documents.=20
> # If a security type of "KERBEROS" is not selected in a Blueprint, then t=
he Cluster Creation template used by override this setting by including "ty=
pe" : "KERBEROS" in the template.  This allows us to support deploying a Bl=
ueprint in both Kerberized and non-Kerberized environments.  This implies t=
hat any Kerberos-specific configuration would need to be included in the Cl=
uster Creation template, but this is already supported by the Blueprints co=
nfiguration overrides.=20
> # If a security type of "KERBEROS" is selected, then the Cluster Creation=
 template should not be able to override this setting to less-secure mode. =
 If the Cluster Creation template is configured to use a different security=
 mechanism, (For example: "type" : "OFF"), then the Blueprints processor sh=
ould treat this as an error condition.  If the Cluster creation template do=
es not specify a "security" tag, then the "security" setting in the Bluepri=
nt should be honored.  In general, we should allow overrides to a more-secu=
re cluster, and forbid overrides for a less-secure cluster. =20
> h2. Blueprint Database Table Changes
> These additions to the Blueprint .json and Cluster Creation Template .jso=
n structure will likely require changes to the Blueprint entity database ta=
bles, already defined in ambari-server. =20
> This current task will encompass any Database table changes needed to mak=
e these additions, and will also likely require some ambari-server Upgrade =
handling.  This will involve using the existing Ambari Upgrade utilities to=
 support moving from older Ambari installs to Ambari 2.2.  The main work he=
re will be updating existing database tables to support the new structure. =
=20
> h2. Backwards compatibility
> Any Blueprints that worked in previous versions of Ambari (non-Kerberized=
) should work as-is in Ambari 2.2, in order to preserve backwards compatibi=
lity.  This means that these new configuration tags must not be required in=
 a non-Kerberized environment. =20
> h2. Blueprint Validation
> The Blueprint validator should be updated to check on the value of the se=
curity "type" field, when it is present.  Once we determine the accepted se=
t of possible values ("OFF" and "KERBEROS", for now), the validator should =
check this, and return a reasonable error to the REST client if an invalid =
value is set. =20
> The kerberos.json (either referenced or embedded) descriptor must be save=
d to the cluster=E2=80=99s artifacts resource prior to Kerberization.=20


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