ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Levas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-17993) Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
Date Tue, 02 Aug 2016 18:56:20 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-17993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Levas updated AMBARI-17993:
----------------------------------
    Description: 
Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
rather than rely on the identity's _name_ attribute. 

Currently, the set of Kerberos identities declared at a service-level or a component-level
can contain identities with unique names.  For example using:

{code}
  "identities": [
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property1.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property1.keytab",
        ...
      }
    },
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property2.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property2.keytab",
        ...
      }
    }
  ]
{code}

Only the first "identity" principal is realized and the additional one is ignored, leaving
the configurations {{service-site/property2.principal}} and {{service-site/property2.keytab}}
untouched when Kerberos is enabled for the service. 

To help this, the 2nd instance can be converted to a reference, overriding only the attributes
the need to be changed - like the configurations. 

{code}
  "identities": [
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property1.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property1.keytab",
        ...
      }
    },
    {
      "name": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property2.principal"
      },
      "keytab": {
        "configuration": "service-site/property2.keytab"
      }
    }
  ]
{code}

This allows for both identity declarations to be realized, however this is limited to only
the 2 instances. If a 3rd instance is needed (to set an additional configuration), it must
look be:

{code}
    {
      "name": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property3.principal"
      },
      "keytab": {
        "configuration": "service-site/property3.keytab"
      }
    }
{code}

However since it's name is the same as the 2nd instance, it will be ignored. 

If explicit references are specified, then multiple uniquely-named identity blocks will be
allowed to reference the same base identity, effectively enabling the ability to declare unlimited
configurations for the same identity definition:

{code}
  "identities": [
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property1.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property1.keytab",
        ...
      }
    },
    {
      "name": "identitiy_reference1",
      "reference": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property2.principal"
      },
      "keytab": {
        "configuration": "service-site/property2.keytab"
      }
    },
    {
      "name": "identitiy_reference2",
      "reference": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property3.principal"
      },
      "keytab": {
        "configuration": "service-site/property3.keytab"
      }
    }
  ]
{code}

NOTE: Backwards compatibility must be maintained when implementing this as to not break existing
Kerberos descriptors. So identity block names the look like paths are to continue to be treated
as references. 


  was:
Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
rather than rely on the identity's _name_ attribute. 

Currently, the set of Kerberos identities declared at a service-level or a component-level
can contain identities with unique names.  For example using:

{code}
  "identities": [
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property1.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property1.keytab",
        ...
      }
    },
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property2.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property2.keytab",
        ...
      }
    }
  ]
{code}

Only the first "identity" principal is realized and the additional one is ignored, leaving
the configurations {service-site/property2.principal} and {service-site/property2.keytab}
untouched when Kerberos is enabled for the service. 

To help this, the 2nd instance can be converted to a reference, overriding only the attributes
the need to be changed - like the configurations. 

{code}
  "identities": [
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property1.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property1.keytab",
        ...
      }
    },
    {
      "name": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property2.principal"
      },
      "keytab": {
        "configuration": "service-site/property2.keytab"
      }
    }
  ]
{code}

This allows for both identity declarations to be realized, however this is limited to only
the 2 instances. If a 3rd instance is needed (to set an additional configuration), it must
look be:

{code}
    {
      "name": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property3.principal"
      },
      "keytab": {
        "configuration": "service-site/property3.keytab"
      }
    }
{code}

However since it's name is the same as the 2nd instance, it will be ignored. 

If explicit references are specified, then multiple uniquely-named identity blocks will be
allowed to reference the same base identity, effectively enabling the ability to declare unlimited
configurations for the same identity definition:

{code}
  "identities": [
    {
      "name": "identity",
      "principal": {
        "value": "service/_HOST@${realm}",
        "configuration": "service-site/property1.principal",
        ...
      },
      "keytab": {
        "file": "${keytab_dir}/service.service.keytab",
        "configuration": "service-site/property1.keytab",
        ...
      }
    },
    {
      "name": "identitiy_reference1",
      "reference": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property2.principal"
      },
      "keytab": {
        "configuration": "service-site/property2.keytab"
      }
    },
    {
      "name": "identitiy_reference2",
      "reference": "/SERVICE/identity",
      "principal": {
        "configuration": "service-site/property3.principal"
      },
      "keytab": {
        "configuration": "service-site/property3.keytab"
      }
    }
  ]
{code}

NOTE: Backwards compatibility must be maintained when implementing this as to not break existing
Kerberos descriptors. So identity block names the look like paths are to continue to be treated
as references. 



> Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
> -------------------------------------------------------------------------------------------
>
>                 Key: AMBARI-17993
>                 URL: https://issues.apache.org/jira/browse/AMBARI-17993
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.4.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>            Priority: Blocker
>              Labels: kerberos_descriptor
>             Fix For: 2.4.0
>
>
> Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
rather than rely on the identity's _name_ attribute. 
> Currently, the set of Kerberos identities declared at a service-level or a component-level
can contain identities with unique names.  For example using:
> {code}
>   "identities": [
>     {
>       "name": "identity",
>       "principal": {
>         "value": "service/_HOST@${realm}",
>         "configuration": "service-site/property1.principal",
>         ...
>       },
>       "keytab": {
>         "file": "${keytab_dir}/service.service.keytab",
>         "configuration": "service-site/property1.keytab",
>         ...
>       }
>     },
>     {
>       "name": "identity",
>       "principal": {
>         "value": "service/_HOST@${realm}",
>         "configuration": "service-site/property2.principal",
>         ...
>       },
>       "keytab": {
>         "file": "${keytab_dir}/service.service.keytab",
>         "configuration": "service-site/property2.keytab",
>         ...
>       }
>     }
>   ]
> {code}
> Only the first "identity" principal is realized and the additional one is ignored, leaving
the configurations {{service-site/property2.principal}} and {{service-site/property2.keytab}}
untouched when Kerberos is enabled for the service. 
> To help this, the 2nd instance can be converted to a reference, overriding only the attributes
the need to be changed - like the configurations. 
> {code}
>   "identities": [
>     {
>       "name": "identity",
>       "principal": {
>         "value": "service/_HOST@${realm}",
>         "configuration": "service-site/property1.principal",
>         ...
>       },
>       "keytab": {
>         "file": "${keytab_dir}/service.service.keytab",
>         "configuration": "service-site/property1.keytab",
>         ...
>       }
>     },
>     {
>       "name": "/SERVICE/identity",
>       "principal": {
>         "configuration": "service-site/property2.principal"
>       },
>       "keytab": {
>         "configuration": "service-site/property2.keytab"
>       }
>     }
>   ]
> {code}
> This allows for both identity declarations to be realized, however this is limited to
only the 2 instances. If a 3rd instance is needed (to set an additional configuration), it
must look be:
> {code}
>     {
>       "name": "/SERVICE/identity",
>       "principal": {
>         "configuration": "service-site/property3.principal"
>       },
>       "keytab": {
>         "configuration": "service-site/property3.keytab"
>       }
>     }
> {code}
> However since it's name is the same as the 2nd instance, it will be ignored. 
> If explicit references are specified, then multiple uniquely-named identity blocks will
be allowed to reference the same base identity, effectively enabling the ability to declare
unlimited configurations for the same identity definition:
> {code}
>   "identities": [
>     {
>       "name": "identity",
>       "principal": {
>         "value": "service/_HOST@${realm}",
>         "configuration": "service-site/property1.principal",
>         ...
>       },
>       "keytab": {
>         "file": "${keytab_dir}/service.service.keytab",
>         "configuration": "service-site/property1.keytab",
>         ...
>       }
>     },
>     {
>       "name": "identitiy_reference1",
>       "reference": "/SERVICE/identity",
>       "principal": {
>         "configuration": "service-site/property2.principal"
>       },
>       "keytab": {
>         "configuration": "service-site/property2.keytab"
>       }
>     },
>     {
>       "name": "identitiy_reference2",
>       "reference": "/SERVICE/identity",
>       "principal": {
>         "configuration": "service-site/property3.principal"
>       },
>       "keytab": {
>         "configuration": "service-site/property3.keytab"
>       }
>     }
>   ]
> {code}
> NOTE: Backwards compatibility must be maintained when implementing this as to not break
existing Kerberos descriptors. So identity block names the look like paths are to continue
to be treated as references. 



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

Mime
View raw message