Re: Review Request 50725: Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50725/#review144600
---
Ship it!
Ship It!
- Oliver Szabo
On Aug. 3, 2016, 12:57 a.m., Robert Levas wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50725/
> ---
>
> (Updated Aug. 3, 2016, 12:57 a.m.)
>
>
> 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/a
Re: Review Request 50725: Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50725/#review144574
---
Ship it!
Ship It!
- Alejandro Fernandez
On Aug. 3, 2016, 12:57 a.m., Robert Levas wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50725/
> ---
>
> (Updated Aug. 3, 2016, 12:57 a.m.)
>
>
> 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/jav
Re: Review Request 50725: Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50725/
---
(Updated Aug. 2, 2016, 8:57 p.m.)
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/ambar
Review Request 50725: Kerberos identity definitions in Kerberos descriptors should explicitly declare a reference
---
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/KerberosIden
