-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50725/
-----------------------------------------------------------

Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, and 
Oliver Szabo.


Bugs: AMBARI-17993
    https://issues.apache.org/jira/browse/AMBARI-17993


Repository: ambari


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:

```
"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",
        ...
      }
    }
  ]
```

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. 

```
"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"
      }
    }
  ]
```

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:

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

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:

```
"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"
      }
    }
  ]
```

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.


Diffs
-----

  
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
 4f5f176 
  
ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/AbstractKerberosDescriptorContainer.java
 fc4e7ad 
  
ambari-server/src/main/java/org/apache/ambari/server/state/kerberos/KerberosIdentityDescriptor.java
 12ade93 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
 4bc1a81 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
 fd26d0e 
  
ambari-server/src/test/java/org/apache/ambari/server/state/kerberos/KerberosDescriptorTest.java
 4b33f38 
  
ambari-server/src/test/java/org/apache/ambari/server/state/kerberos/KerberosIdentityDescriptorTest.java
 79a861d 
  
ambari-server/src/test/resources/kerberos/test_get_referenced_identity_descriptor.json
 307a1e1 

Diff: https://reviews.apache.org/r/50725/diff/


Testing
-------

Manually tested

# Local test results: PENDING

# Jenkins test results: PENDING


Thanks,

Robert Levas

Reply via email to