[
https://issues.apache.org/jira/browse/AMBARI-14516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-14516:
----------------------------------
Attachment: AMBARI-14516_trunk_01.patch
AMBARI-14516_branch-rbac-sso_01.patch
AMBARI-14516_branch-2.2_01.patch
> Failed to deploy Kerberized cluster via blueprint with custom principal name
> ----------------------------------------------------------------------------
>
> Key: AMBARI-14516
> URL: https://issues.apache.org/jira/browse/AMBARI-14516
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.2.1
> Reporter: Robert Levas
> Assignee: Robert Levas
> Priority: Critical
> Labels: kerberos_descriptor
> Fix For: 2.2.1
>
> Attachments: AMBARI-14516_branch-2.2_01.patch,
> AMBARI-14516_branch-rbac-sso_01.patch, AMBARI-14516_trunk_01.patch
>
>
> Failed to deploy Kerberized cluster via Blueprint with custom principal name
> set in Kerberos descriptor declared in _Cluster Creation Template_ like
> {code}
> ...
> "security": {
> "type": "KERBEROS",
> "kerberos_descriptor": {
> "identities": [
> {
> "name": "smokeuser",
> "principal": {
> "value": "smokeuser9jJevBQAYGQWnRkuapSEp@${realm}"
>
> }
> }
> ]
> }
> },
> ...
> {code}
> The following error (shown in ambari-server.log) was encountered while the
> cluster was being built:
> {noformat}
> Failed to create keytab for [email protected],
> missing cached file
> {noformat}
> h3. Cause
> This was caused because the Kerberos descriptor in the _Blueprint_ or
> _Cluster Creation Template_ did not declare the type property of the
> principal being updated. This caused the logic in Ambari to assume the
> principal was a _service_ principal rather than a _user_ (or headless)
> principal. Because of this, when merging the updates to the default Kerberos
> descriptor (from the stack), the {{smokeuser}} principal type was changed
> _user_ to _service_. Thus it was skipped over when the _Blueprints_ process
> executed the phase to ensure (and cache) headless identities.
> The bug is in the logic parsing the Kerberos descriptor. By not specifying a
> principal type, the logic assumes the principal type is _service_; however in
> this case, the principal type needs to be {{null}}, so that when the
> user-specified Kerberos descriptor is merged with the default Kerberos
> descriptor, the default principal type is not changed.
> *NOTE:* This is not limited to _Blueprints_, the issue will cause issues if
> the specified Kerberos descriptor artifact is missing {{principal/type}}
> properties as well. See [Set the Kerberos
> Descriptor|https://cwiki.apache.org/confluence/display/AMBARI/Automated+Kerberizaton#AutomatedKerberizaton-SettheKerberosDescriptor]
> h3. Solution
> Change the logic it the Kerberos descriptor parser to allow for the principal
> type to be {{null}}. Handle this value being {{null}} by consumers of this
> data such that {{null}} indicates the default value of {{service}}. This will
> keep the current behavior consistent, and also allow for the merging facility
> to properly merge principal updates - like changing the principal name
> pattern without needing to specify the principal type as well.
> h3. Workaround
> Explicitly set the {{type}} property of _user_ (or headless) principals in
> the Kerberos descriptor:
> {code}
> ...
> "security": {
> "type": "KERBEROS",
> "kerberos_descriptor": {
> "identities": [
> {
> "name": "smokeuser",
> "principal": {
> "type" : "USER",
> "value": "smokeuser9jJevBQAYGQWnRkuapSEp@${realm}"
>
> }
> }
> ]
> }
> },
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
