ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Levas (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMBARI-14516) Failed to deploy Kerberized cluster via blueprint with custom principal name
Date Tue, 29 Dec 2015 12:52:49 GMT
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 smokeuser9jJevBQAYGQWnRkuapSEp@EXAMPLE.COM, 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)

Mime
View raw message