Issues Fixed in Key Trustee KMS
The following sections describe issues fixed in each Key Trustee KMS release.
- Issues Fixed in Key Trustee KMS 5.16.0
- Issues Fixed in Key Trustee KMS 5.15.1
- Issues Fixed in Key Trustee KMS 5.15.0
- Issues Fixed in Key Trustee KMS 5.14.0
- Issues Fixed in Key Trustee KMS 5.13.1
- Issues Fixed in Key Trustee KMS 5.13.0
- Issues Fixed in Key Trustee KMS 5.12.0
- Issues Fixed in Key Trustee KMS 5.11.0
- Issues Fixed in Key Trustee KMS 5.10.0
- Issues Fixed in Key Trustee KMS 5.9.0
- Issues Fixed in Key Trustee KMS 5.8.2
- Issues Fixed in Key Trustee KMS 5.8.0
- Issues Fixed in Key Trustee KMS 5.7.4
- Issues Fixed in Key Trustee KMS 5.7.1
- Issues Fixed in Key Trustee KMS 5.7.0
- Issues Fixed in Key Trustee KMS 5.5.4
- Issues Fixed in Key Trustee KMS 5.5.0
- Issues Fixed in Key Trustee KMS 5.4.3
Issues Fixed in Key Trustee KMS 5.16.0
CDH upgrade failure
When upgrading to Key Trustee KMS 5.15.0 or 5.15.1 from Key Trustee KMS 5.14.0 or lower, and performing a rolling restart (instead of a full restart), the first Key Trustee KMS instance to restart may fail to come up and present an error.
Cloudera Bug: KT-6499
Error when enabling Key Trustee KMS HA mode
Unable to verify private key match between KMS hosts.This error will be corrected automatically after the GPG private keys are synchronized and the KMS service is restarted to pick up the new configuration. No user intervention is required.
Cloudera Bug: KT-6471
Issues Fixed in Key Trustee KMS 5.15.1
Validation fails if hostname command returns shortname
If the hostname command on the OS returns shortname, and the core-site.xml of the KMS process has a hadoop.security.key.provider.path with a fully qualified domain name (FQDN), then the znodes will be created with the shortname. Consequently, when KMS 1 checks the fingerprint of KMS 2, it will expect the FQDN as the znode, and fail the validation.
Issues Fixed in Key Trustee KMS 5.15.0
For new features in Key Trustee KMS 5.15.0, see What's New in Key Trustee KMS 5.15.0.
Issues Fixed in Key Trustee KMS 5.14.0
For new features in Key Trustee KMS 5.14.0, see What's New in Key Trustee KMS 5.14.0.
Issues Fixed in Key Trustee KMS 5.13.1
Cannot re-encrypt an encryption zone if a previous re-encryption on it was canceled
When canceling a re-encryption on an encryption zone, the status of the re-encryption would remain at "Processing". When this occurred, future re-encrypt commands for this encryption zone failed inside the NameNode, and the re-encryption never completed. This issue has been fixed.
Issues Fixed in Key Trustee KMS 5.13.0
For new features in Key Trustee KMS 5.13.0, see What's New in Key Trustee KMS 5.13.0.
Issues Fixed in Key Trustee KMS 5.12.0
For new features in Key Trustee KMS 5.12.0, see What's New in Key Trustee KMS 5.12.0.
Issues Fixed in Key Trustee KMS 5.11.0
For new features in Key Trustee KMS 5.11.0, see What's New in Key Trustee KMS 5.11.0.
Issues Fixed in Key Trustee KMS 5.10.0
For new features in Key Trustee KMS 5.10.0, see What's New in Key Trustee KMS 5.10.0.
Issues Fixed in Key Trustee KMS 5.9.0
For new features in Key Trustee KMS 5.9.0, see What's New in Key Trustee KMS 5.9.0.
Issues Fixed in Key Trustee KMS 5.8.2
Issues Fixed in Key Trustee KMS 5.8.0
For new features in Key Trustee KMS 5.8.0, see What's New in Key Trustee KMS 5.8.0.
Issues Fixed in Key Trustee KMS 5.7.4
Issues Fixed in Key Trustee KMS 5.7.1
Issues Fixed in Key Trustee KMS 5.7.0
For new features in Key Trustee KMS 5.7.0, see What's New in Key Trustee KMS 5.7.0.
Issues Fixed in Key Trustee KMS 5.5.4
Key Trustee KMS configuration file and keys are stored in a volatile location
If the Key Trustee KMS 5.5.0 parcel is deactivated, any existing GPG keys are also deactivated. If the parcel is then reactivated, new GPG keys (used to create an authenticated and private communication channel with the Key Trustee Server) are generated. The existing GPG keys that were in use before the deactivation are not lost; however, they become inactive. If remedial action is not taken before deactivation, this can result in a loss of access to HDFS Encryption Zone keys generated with the older set of GPG keys. This in turn leads to loss of access to all data in all encryption zones. As long as the Key Trustee KMS parcel directory is not deleted, access can be restored. Assistance from Cloudera Support may be required. See TSB 2016-121 for more information (requires login to the Cloudera Support Portal).
Cloudera Bug: KT-2460
Issues Fixed in Key Trustee KMS 5.5.0
Key Trustee KMS intermittently fails to start due to permission issues
java.io.IOException: TrusteeKeyProvider initialization failed. at com.cloudera.keytrustee.TrusteeKeyProvider.createInitialClient(TrusteeKeyProvider.java:212) at com.cloudera.keytrustee.TrusteeKeyProvider.<init>(TrusteeKeyProvider.java:114) at com.cloudera.keytrustee.TrusteeKeyProvider.<init>(TrusteeKeyProvider.java:86) [...] Caused by: java.io.FileNotFoundException: /var/lib/kms-keytrustee/keytrustee/.keytrustee/keytrustee.conf (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:221) at java.io.FileOutputStream.<init>(FileOutputStream.java:171) at com.cloudera.keytrustee.impl.ClientFactoryImpl.createNewClient(ClientFactoryImpl.java:129) ... 30 more