Robert Levas created AMBARI-14516:
-------------------------------------
Summary: 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
Fix For: 2.2.1
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)