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

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

When a new Key Trustee KMS instance is added to an existing Key Trustee KMS service, the new instance may initially fail to start up and return the error message:
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

KMS does not fail over to Passive Key Trustee Server in some network failure scenarios

In some situations, if the Active Key Trustee Server is unreachable on the network, Key Trustee KMS does not fail over to the Passive Key Trustee Server.

Cloudera Bug: KT-3289

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

KMS does not fail over to Passive Key Trustee Server in some network failure scenarios

In some situations, if the Active Key Trustee Server is unreachable on the network, Key Trustee KMS does not fail over to the Passive Key Trustee Server.

Cloudera Bug: KT-3289

Issues Fixed in Key Trustee KMS 5.7.1

KMS ACLs read from wrong file

The UNDELETE and PURGE ACL entries were being read from kms-site.xml instead of kms-acls.xml.

Cloudera Bug: KT-2857

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

KMS ACLs read from wrong file

The UNDELETE and PURGE ACL entries were being read from kms-site.xml instead of kms-acls.xml.

Cloudera Bug: KT-2858

Issues Fixed in Key Trustee KMS 5.5.0

Key Trustee KMS intermittently fails to start due to permission issues

Key Trustee KMS sometimes fails to start with the following error:
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

Key Trustee KMS starts up successfully even if it cannot contact the Key Trustee Server

Key Trustee KMS starts successfully when it cannot connect to the Key Trustee Server, instead of properly failing to start.

Issues Fixed in Key Trustee KMS 5.4.3

Host Component page display

The Host Component page now displays the package version for the KMS Trustee Key Provider.

Cloudera Bug: OPSAPS-25692