Known Issues in Cloudera Navigator 6.3.0 Encryption
The following sections describes known issues in the encryption components of Cloudera Navigator 6.3.0, grouped by component:
Known Issues in Cloudera Navigator Key Trustee Server 6.1.0
Additional Key Trustee Server process appears after key creation when passive database is stopped
ps -ef | grep keytrustee | grep -v postgresIn normal operations there should be only one Key Trustee Server process running.
Affected Version: 6.0.0, 6.1.0
Cloudera Bug: KT-6684
Workaround: These extra Key Trustee Server processes do not cause any errors with the Key Trustee Server, but they will not be cleaned up properly when the Key Trustee Server is shut down. To fully shut down the Key Trustee Server when there are extra processes running, stop the Key Trustee Server service, and then kill any remaining processes.
Key Trustee Server active database setup fails when command line configuration specifies non-default database port
If the Key Trustee Server is configured from the command line to use a non-default database port (the default port is 11381), then when the Key Trustee Server service is added to Cloudera Manager, the first database startup fails.
Affected Version: 6.0.0, 6.1.0
Cloudera Bug: KT-6238
- Log in to the Key Trustee Server and manually stop/start the databases:
service keytrustee-db stop
Make sure that the postmaster.pid file, which is located in the database directory, no longer exists. If necessary, replace /var/lib/keytrustee/db in the following command with the appropriate database directory for your system:# ls /var/lib/keytrustee/db/postmaster.pid
If postmaster.pid has not been cleaned up, then use the pg_ctl utility to stop the database directly:# pg_ctl stop
- Return to the Cloudera Manager home page where the Key Trustee Server service is listed.
- Go into the Key Trustee Server service configuration and for Key Trustee Server Database Port, specify the port that was configured during the command line configuration.
- Redeploy the Key Trustee Server configuration and restart the service.
Key Trustee KMS cannot connect to Key Trustee Server using TLS versions other than 1.0 on JDK 7
If you have configured Key Trustee Server to use a TLS version other than 1.0, Key Trustee KMS fails to connect to Key Trustee Server, and key operations fail when using JDK 7.
Workaround: Use TLS version 1.0 only, or JDK 8.
Key Trustee Server cannot use TLS version 1.2 on RHEL 6
Configuring Key Trustee Server to use TLS version 1.2 causes Key Trustee Server to be unable to start.
Workaround: Use your operating system package manager to upgrade the pyOpenSSL package to version 1.4 or higher, or do not configure Key Trustee Server to use TLS version 1.2.
Known Issues in Cloudera Navigator Key HSM 6.3.0
Thales Key HSM won't work with OpenJDK 11
Thales Key HSM is unsupported because the Thales client Java libraries do not support Java 11.
Affected Version: 6.3.0
Cloudera Bug: KT-6854
Workaround: None.
Roll key command throws an exception and cannot retrieve metadata for key
When using Key Trustee KMS with Key Trustee Server and Key HSM (backed by an HSM device), if there is significant (> 15 ms ping time) network latency between the Key Trustee Server and the HSM device, then EDEK generation errors can occur during the roll key operation. These errors manifest in the KMS log as errors on the generateEncryptedKey operation. The KMS will recover from these errors on its own, but they may represent a nuisance to the operator.
Affected Version: 6.0.0, 6.1.0, 6.2.0, 6.3.0
Cloudera Bug: KT-5646
Workaround: When these errors occur, you can use the hadoop key list -metadata command to confirm whether or not the key roll was successful, despite the error condition.
Key HSM Luna setup not showing the correct login status
When running the keyhsm setup luna command, you are prompted for the Luna HSM slot number and login password. Key HSM then attempts to log into the Luna HSM to verify these settings are correct. In some circumstances, the setup script reports that the login was successful, even if it failed.
Affected Version: 6.0.0, 6.1.0, 6.2.0, 6.3.0
Cloudera Bug: KT-6623
Workaround: Any incorrect settings will cause the Key HSM service to throw an exception upon startup and exit. If the Key HSM service does not start correctly, check the log for the message: "Unable to sign into Luna HSM server. Please rerun application with 'setup' option to configure password." If this message appears, re-run the keyhsm setup luna command, and enter the correct slot number and login password.
Known Issues in Cloudera Navigator Key Trustee KMS 6.3.0
The Key Trustee KMS service fails to start if the Trust Store is configured without also configuring the Keystore
If you configure the Key Trustee KMS service Key Management Server Proxy TLS/SSL Certificate Trust Store File and Key Management Server Proxy TLS/SSL Certificate Trust Store Password parameters without also configuring the Key Management Server Proxy TLS/SSL Server JKS Keystore File Location and Key Management Server Proxy TLS/SSL Server JKS Keystore File Password parameters, the Key Trustee KMS service does not start.
Workaround: Configure all Trust Store and Keystore parameters.
Key Trustee KMS backup script fails if PostgreSQL versions lower than 9.3 are installed
If PostgreSQL versions lower than 9.3 are installed on the Key Trustee KMS host, the ktbackup.sh script fails with an error similar to the following:
pg_dump: server version: 9.3.11; pg_dump version: 9.2.14 pg_dump: aborting because of server version mismatch
Workaround: Uninstall the lower PostgreSQL version.
Known Issues in Cloudera Navigator HSM KMS 6.3.0
Encryption zone key is not deleted after migrating from Key Trustee KMS to HSM KMS
After migrating keys from the Key Trustee KMS to the HSM KMS, the HSM KMS service should be restarted. Until it is restarted, any keys that are deleted after the migration may still be cached. If a deleted key is cached, then the data encrypted with that key can still be accessed even though the key has been deleted.
Affected Version: 6.0.0, 6.1.0, 6.2.0, 6.3.0
Cloudera Bug: KT-6434
Workaround: Restart the HSM KMS service after the key migration is complete.
Known Issues in Cloudera Navigator Encrypt 6.2.0
Navigator Encrypt cannot create an ACL when Key Trustee Server is down
Navigator Encrypt cannot create new ACLs when the Key Trustee Server is down. Navigator Encrypt will attempt to verify the master key with the Key Trustee Server when adding ACLs, even if the master key should already have been cached on the local system. If it can't communicate with the Key Trustee Server, the add ACL request will fail.
Affected Version: 6.1.0, 6.2.0
Cloudera Bug: KT-6390
Workaround: Make sure the Key Trustee Server is running before making modifications to Navigator Encrypt ACLs.
Issue with navencrypt-mount service status message
Affected Version: 6.0.0, 6.1.0, 6.2.0
Cloudera Bug: KT-6309
On RHEL 7, the service navencrypt-mount stop command might return a successful exit status message, even if there was a problem stopping Navigator Encrypt. This is not an issue with the navencrypt-mount service command; rather, it is a problem with the message output.
# lsmod | grep navencrypt navencryptfs 101407 0Alternatively, you can verify that the navencrypt mount points successfully dismounted by checking the output of the df or mount commands.
Workaround: None.