[
https://issues.apache.org/jira/browse/AMBARI-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673455#comment-13673455
]
Siddharth Wagle commented on AMBARI-2174:
-----------------------------------------
isPersisted --> more of a convention.
http://stackoverflow.com/questions/3874350/naming-conventions-for-java-methods-that-return-booleanno-question-mark
We should follow it other places.
MASTER_KEY_FILENAME_DEFAULT - Path is /var/lib/ambari-server/keys/master (Maybe
we should be able to take full path as param)
should loadCredentialProvider() use a lock around instantiating the provider -
Unnecessary since only read operation
isMasterKeyPersisted() - Yes, this makes sure we look for the file and load it.
If credential not in store we use what is in the file.
Could we have used "update_ambari_properties" instead of defining
"update_properties"?
Cannot reuse, "update_ambari_properties" updates from old file to new file,
"update_properties" is from live map to file.
> 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-latest.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
