[
https://issues.apache.org/jira/browse/AMBARI-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13671832#comment-13671832
]
Sumit Mohanty commented on AMBARI-2174:
---------------------------------------
*ambari-server/conf/unix/ambari.properties*
* ...isPersisted --> ...persisted (other true/false properties do not seem to
use "is"
*ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java*
* sort the import statements
* MASTER_KEY_FILENAME_DEFAULT - should we use a more descriptive name such as
"master.key" or "ambari.master.key"?
* credentialProvider (it will be initialized to null by default)
* should loadCredentialProvider() use a lock around instantiating the provider?
* getDatabasePassword() - use { } within the if-else - similar to
readPasswordFromStore
* isMasterKeyPersisted() - properties.getProperty(MASTER_KEY_PERSISTED,
"true"); - this will return true if the property does not exist. Is this by
design?
* getMasterKeyLocation - Can you check the default value for
MASTER_KEY_LOCATION - I was not sure if
{code}properties.getProperty(SRVR_KSTR_DIR_KEY +
File.separator + MASTER_KEY_FILENAME_DEFAULT,
SRVR_KSTR_DIR_DEFAULT + File.separator +
MASTER_KEY_FILENAME_DEFAULT){code} produces the desired default.
*ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java*
* does not seem to have any changes.
*ambari-server/src/main/java/org/apache/ambari/server/security/CertificateManager.java*
* no change here either
*ambari-server/src/main/python/ambari-server.py*
* Could we have used "update_ambari_properties" instead of defining
"update_properties"
TBD: ambari-server/src/main/java/org/apache/ambari/server/security/encryption
> Eliminate cleartext LDAPS credentials from Ambari props files
> -------------------------------------------------------------
>
> Key: AMBARI-2174
> URL: https://issues.apache.org/jira/browse/AMBARI-2174
> Project: Ambari
> Issue Type: Task
> Components: controller
> Affects Versions: 1.2.5
> Reporter: Siddharth Wagle
> Assignee: Siddharth Wagle
> Fix For: 1.2.5
>
> Attachments: AMBARI-2174.patch
>
>
> Observations:
> - Currently we use the Java Keystore for storing server and agent SSL
> certificates. The keystore is a storage facility for cryptographic keys and
> certificates and is guarded by a password.
> Presently what we do is generate a random 50 character long alphanumeric
> keystore password, the first time ambari starts with permissions 644. (should
> be 600)
> {noformat}
> -rw-r--r--. 1 root root 50 May 13 13:49 pass.txt
> {noformat}
> - Database password in ambari.properties, this is not clear text and is store
> in a file with appropriate ACL.
> {noformat}
> -rw-------. 1 root root 7 May 13 13:49 /etc/ambari-server/conf/password.dat
> {noformat}
> Need to discuss the flow of enabling LDAP access to Ambari in order to
> suggest a flexible approach.
> Important considerations:
> - Any cryptographic technique that requires encryption and decryption has
> understood weakness that the private key is protected by the appropriate ACL.
> Even if we encrypt passwords in the configuration files, the key used for
> achieving the encryption needs to be protected.
> - One decent solution is, prompt the user for a passphrase and use the
> non-invertible secure digest (such as sha-1) of the password to lock the
> keystore. This same password can be used to encrypt LDAP credentials. In this
> approach we need to prompt the admin to provide the LDAP password when
> configuring a LDAP user for the first time and then write the encrypted
> password into the configuration file. Alternately, we can ask for the same
> during ambari-server setup, but that would be less flexible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
