[
https://issues.apache.org/jira/browse/AMBARI-17993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15406575#comment-15406575
]
Hudson commented on AMBARI-17993:
---------------------------------
SUCCESS: Integrated in Ambari-trunk-Commit #5447 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5447/])
AMBARI-17993. Kerberos identity definitions in Kerberos descriptors (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=5ddeb09897fbf015f2a63fe33c937a99e027bdbe])
*
ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/KerberosIdentityDescriptor.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
*
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
*
ambari-server/src/test/java/org/apache/ambari/server/state/kerberos/KerberosIdentityDescriptorTest.java
*
ambari-server/src/test/java/org/apache/ambari/server/state/kerberos/KerberosDescriptorTest.java
*
ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/AbstractKerberosDescriptorContainer.java
*
ambari-server/src/test/resources/kerberos/test_get_referenced_identity_descriptor.json
*
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
> 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)
