You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Robert Levas (JIRA)" <ji...@apache.org> on 2015/12/30 13:20:49 UTC
[jira] [Updated] (AMBARI-14516) Failed to deploy Kerberized cluster
via blueprint with custom principal name
[ 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 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)