Keystore password in clear in /etc/default/cloudera-scm-server

[#1]

I successfully configured LDAPS authentication for Cloudera Manager by following the documentation (https://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_external_auth.html)

The certificate for the LDAP server is stored in a custom JKS file (protected by password) and based on the documentation, the path and password to that JKS file, could be provided in the /etc/default/cloudera-scm-server config file, as:

export CMF_JAVA_OPTS="-Xmx2G -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError / -XX:HeapDumpPath=/tmp -Djavax.net.ssl.trustStore=/usr/java/default/jre/lib/security/jssecacerts / -Djavax.net.ssl.trustStorePassword=changeit"

Everything works fine, however, the password is in clear text and the file is world readable.

-Is there a standard way to obfuscate/encrypt the password in the config file?
-Is it ok to set the permissions to 640?

[#2]

@hamed2005,

The password should not be necessary since the keystore is only being used as a trust store (needing only read access).  Cloudera Manager would only need to read from the file.

Try removing -Djavax.net.ssl.trustStorePassword=changeit and then restart Cloudera Manager.   If that works fine for you, I'll work with the Cloudera documentation team to get our documentation updated to remove the password.

-Ben

[#3]

Hi @bgooley

Thanks for your reply.

The password is necessary to avoid malicious users to modify the truststore's contents (e.g. adding new certificates) and also is needed to check the integrity of the store's contents.

Removing the -Djavax.net.ssl.trustStorePassword=changeit causes the following exception:

Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
        at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:780)
        at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
        at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
        at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
        at java.security.KeyStore.load(KeyStore.java:1445)
        at com.mysql.jdbc.ExportControlled.getSSLSocketFactoryDefaultOrConfigured(ExportControlled.java:428)
        ... 23 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
        at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:778)
        ... 28 more

 -Hamed

[#4]

Also, for permissions, the file needs to be readable by any users accessing it.

It is not a sensitive file since it does not contain private key material.  The role of the "trust store" is to allow clients to be able to define server certificates as "trusted" so the intent of the jssecacerts file is to only contain certificates of certificate authorities that are trusted.

[#5]

@bgooley
Regarding permissions, I meant the permissions for the /etc/default/cloudera-scm-server and not the JKS truststore file.

-Hamed

[#6]

@hamed2005,

The password on the file does not matter for read operations.  My point was that Cloudera Manager does not need to know the password of the truststore to access what it needs.

I tested on CM 5.13.1 with the following in /etc/default/cloudera-scm-server and was able to auth to LDAPS fine:

export CMF_JAVA_OPTS="-Xmx2G -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djavax.net.ssl.trustStore=/usr/java/jdk1.8.0_60/jre/lib/security/jssecacerts"

What does your "export" line look like?

[#7]

@bgooley,
Thanks for your reply.

This setting causes the error I mentioned:

export CMF_JAVA_OPTS="-Xmx2G -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djavax.net.ssl.trustStore=/opt/cloudera/security/pki/truststore.jks"

And this works:

export CMF_JAVA_OPTS="-Xmx2G -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djavax.net.ssl.trustStore=/opt/cloudera/security/pki/truststore.jks -Djavax.net.ssl.trustStorePassword=<PASSWORD REMOVED>"

[#8]

@hamed2005,

I looked more closely at the exception and now think I understand...

com.mysql.jdbc.ExportControlled.getSSLSocketFactoryDefaultOrConfigured(ExportControlled.java:428)

It seems that the MySQL JDBC driver may require a password.  I was testing in an environment where I wasn't using TLS for my db connection, so it didn't matter.

Not sure how to get around this... I'll let you know if I come up with something