[
https://issues.apache.org/jira/browse/AMBARI-22571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276908#comment-16276908
]
Robert Levas edited comment on AMBARI-22571 at 12/4/17 3:06 PM:
----------------------------------------------------------------
Thanks [~akovalenko]!
[~smolnar], To allow for something similar with the Ambari configurations, we
should provide metadata with the Ambari-level configurations. I think this can
be done in a single API call rather than force the front end (or other
consumer) to make multiple calls to get the property metadata.
[~akovalenko], Do you have an opinion on this? The interface can mimic the way
service configurations are done (with one API call to get the configuration
metadata and one to get the configuration values) or the interface can be built
so that only a single API call is needed to get the property metadata and
values at the same time.
For example:
{noformat:title=URL}
GET
/api/v1/services/AMBARI/components/AMBARI_SERVER/configurations/ldap-configuration
{noformat}
{code:title=Payload}
{
"Configuration": {
"category": "ldap-configuration",
"component_name" : "AMBARI_SERVER",
"service_name" : "AMBARI",
"properties": {
"ambari.ldap.connectivity.server.host": "ldap.forumsys.com",
"ambari.ldap.connectivity.server.port": "389",
"ambari.ldap.connectivity.anonymous_bind": "true",
"ambari.ldap.attributes.user.search_base": "dc=example,dc=com",
"ambari.ldap.attributes.user.object_class": "person",
"ambari.ldap.attributes.user.name_attr": "uid",
"ambari.ldap.attributes.group.object_class": "groupOfUniqueNames",
"ambari.ldap.attributes.group.name_attr": "cn",
"ambari.ldap.attributes.group.member_attr": "uniqueMember",
"ambari.ldap.attributes.group.search_base": "dc=example,dc=com"
},
"property-types": {
"ambari.ldap.connectivity.server.host": "plaintext",
"ambari.ldap.connectivity.server.port": "plaintext",
"ambari.ldap.connectivity.anonymous_bind": "plaintext",
"ambari.ldap.attributes.user.search_base": "plaintext",
"ambari.ldap.attributes.user.object_class": "plaintext",
"ambari.ldap.attributes.user.name_attr": "plaintext",
"ambari.ldap.attributes.group.object_class": "plaintext",
"ambari.ldap.attributes.group.name_attr": "plaintext",
"ambari.ldap.attributes.group.member_attr": "plaintext",
"ambari.ldap.attributes.group.search_base": "plaintext",
"ambari.ldap.connectivity.bind_dn": "plaintext",
"ambari.ldap.connectivity.bind_password": "password",
"ambari.ldap.connectivity.trust_store": "plaintext",
"ambari.ldap.connectivity.trust_store.type": "plaintext",
"ambari.ldap.connectivity.trust_store.path": "plaintext",
"ambari.ldap.connectivity.trust_store.password": "password"
}
}
}
{code}
BTW, for information on this API entry point as of now, see - AMBARI-22418 and
AMBARI-22481
was (Author: rlevas):
Thanks [~akovalenko]!
[~smolnar], To allow for something similar with the Ambari configurations, we
should provide metadata with the Ambari-level configurations. I think this can
be done in a single API call rather than force the front end (or other
consumer) to make multiple calls to get the property metadata.
[~akovalenko], Do you have an opinion on this? The interface can mimic the way
service configurations are done (with one API call to get the configuration
metadata and one to get the configuration values) or the interface can be built
so that only a single API call is needed to get the property metadata and
values at the same time.
For example:
{noformat:title=URL}
GET
/api/v1/services/AMBARI/components/AMBARI_SERVER/configurations/ldap-configuration
{noformat}
{code:title=Payload}
{
"Configuration": {
"category": "ldap-configuration",
"properties": {
"ambari.ldap.connectivity.server.host": "ldap.forumsys.com",
"ambari.ldap.connectivity.server.port": "389",
"ambari.ldap.connectivity.anonymous_bind": "true",
"ambari.ldap.attributes.user.search_base": "dc=example,dc=com",
"ambari.ldap.attributes.user.object_class": "person",
"ambari.ldap.attributes.user.name_attr": "uid",
"ambari.ldap.attributes.group.object_class": "groupOfUniqueNames",
"ambari.ldap.attributes.group.name_attr": "cn",
"ambari.ldap.attributes.group.member_attr": "uniqueMember",
"ambari.ldap.attributes.group.search_base": "dc=example,dc=com"
},
"property-types": {
"ambari.ldap.connectivity.server.host": "plaintext",
"ambari.ldap.connectivity.server.port": "plaintext",
"ambari.ldap.connectivity.anonymous_bind": "plaintext",
"ambari.ldap.attributes.user.search_base": "plaintext",
"ambari.ldap.attributes.user.object_class": "plaintext",
"ambari.ldap.attributes.user.name_attr": "plaintext",
"ambari.ldap.attributes.group.object_class": "plaintext",
"ambari.ldap.attributes.group.name_attr": "plaintext",
"ambari.ldap.attributes.group.member_attr": "plaintext",
"ambari.ldap.attributes.group.search_base": "plaintext",
"ambari.ldap.connectivity.bind_dn": "plaintext",
"ambari.ldap.connectivity.bind_password": "password",
"ambari.ldap.connectivity.trust_store": "plaintext",
"ambari.ldap.connectivity.trust_store.type": "plaintext",
"ambari.ldap.connectivity.trust_store.path": "plaintext",
"ambari.ldap.connectivity.trust_store.password": "password"
}
}
}
{code}
BTW, for information on this API entry point as of now, see - AMBARI-22418 and
AMBARI-22481
> Handle passwords/sensitive data in Ambari configuration properties
> ------------------------------------------------------------------
>
> Key: AMBARI-22571
> URL: https://issues.apache.org/jira/browse/AMBARI-22571
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Minor
> Labels: config, security
> Fix For: trunk
>
>
> Passwords and other sensitive data stored as values to properties in Ambari
> configurations need to be masked or not stored in cleartext.
> For example,
> {{ldap-configuration/ambari.ldap.connectivity.trust_store.password}} and
> ldap-{{configuration/ambari.ldap.connectivity.bind_password}}.
> If the Ambari credential store is enabled (which might be by default as of
> Ambari 3.0.0), the sensitive date can be stored there like we do when
> sensitive data is to be stored in the ambari.properties file - see
> {{org.apache.ambari.server.security.encryption.CredentialStoreService}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
