[
https://issues.apache.org/jira/browse/AMBARI-17993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-17993:
----------------------------------
Status: Patch Available (was: In Progress)
> 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
>
> Attachments: AMBARI-17993_branch-2.4_01.patch,
> AMBARI-17993_trunk_01.patch
>
>
> 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)
