Encryption of the data stored within the data grid of Hazelcast (the technology underpinning our deployment groups and clustering in Payara Platform 5) has until now required a Hazelcast Enterprise subscription (see Payara Scales). While this remains an option for those who would like the additional features it provides (such as WAN replication), we’ve begun introducing this particular feature into Payara Server itself to provide it to you without needing an additional subscription.
Is This Different to HTTPS or SSL/TLS?
Yes! HTTPS, SSL, and TLS are forms of secure transport or communication – their use does not necessarily mean that the actual information being transported is encrypted. What this feature does is encrypt the data that’s being stored in-memory and replicated between the instances. To use buzzwords: this feature provides end-to-end encryption, in comparison to TLS which solely provides encryption of data in transit.
How Do I Use It?
A key is used by Payara Server to perform the actual encryption and decryption of data. This key can be generated using the following command:
This command generates a key using the master password – the same one used to access the key store used by Payara Server.
Note that if you change the master password after generating your key, you’ll need to regenerate the key since it was created using the old (and now incorrect) password.
Don’t worry about having to generate this key on every single Payara Server instance – it propagates across to them in the same way that the key and trust stores are synchronised between the DAS and the other instances.
Enabling encryption of the data grid itself is controlled by the set-hazelcast-configuration asadmin command, with the new --encryptdatagrid parameter:
set-hazelcast-configuration --encryptdatagrid true
This is a domain-wide setting, so once again, you don’t need to worry about applying this to each of your instance’s configs. Since it is a domain-wide setting, this means that we don’t currently support hybrid setups where encryption is enabled on specific clusters within a domain and not on others.
Once you’ve generated your key and enabled encryption, simply restart all of your instances and any data stored in the data grid store should now be encrypted!
Similar to the change-master-password command, you are required to stop your domain to run the generate-encryption-key command – this is by design so that you don’t suddenly switch the key being used to encrypt or decrypt data on the fly.
In the same vein, while the set-hazelcast-configuration command does support the --dynamic flag to apply changes without a restart, this is ignored for changing the data grid encryption settings so that you don’t suddenly start or stop encrypting and decrypting data within the data grid.
Currently, while the encryption key will be propagated from the DAS to each instance in the domain, it is required that you perform a full sync for a regenerated encryption key to be propagated to each instance (or manually delete the existing key before starting the instance); if an instance has already had an encryption key propagated to it, Payara Server won’t overwrite the key.
What Gets Encrypted?
Currently, the following will get encrypted:
- Web session persistence data
- Stateful Session Bean persistence data
- Request traces
- Historic health checks
For web sessions and stateful sessions beans, make sure that you’ve configured the availability store for their respective containers to use Hazelcast (it defaults to this). Nothing else is required!
The Techie Bit: How is it Encrypted?
We opted to use symmetric encryption, protected, as previously mentioned, using the master password. This means that the same key is used by each member of the data grid to encrypt and decrypt the data.
The symmetric key used for the encryption & decryption is itself a pure random key, the master password is used with a key derivation function to generate a second key for storing and reading the actual key safely to/from the disk (passwords are frequently short and easy to crack).
The keys we generate and use are 256-bit AES keys, and we utilise an initialisation vector & salt for each call of encryption to help prevent any statistical pattern recognition.
As noted in the title, this feature is being released in tech preview; further fixes and quality of life changes will come in future releases. Also, I’m just going to reiterate that our implementation of this feature does not preclude the shuttering of Payara Scales – Hazelcast Enterprise provides a wealth of features for those who require them.
Aside from that, I hope you find the feature useful (and don’t immediately crack the encryption!)
Subscribe to the Tech Blog and Get Notified About Payara Platform Releases