Parts of the configuration are considered extra sensitive. When dumping the configuration to file, using version control systems to manage versions of the configuration or viewing the configuration using any interface it’s often desired to be able to lock certain parts.
The crypto subtree under /processing/crypto is therefore encrypted. By default it uses a known key by the system, but in production systems this should be replaced with a production key instead.
crypto
/processing/crypto
It is possible to setup different keys for different environments and using command line arguments when starting Curity to re-encrypt the data using new keys.
Important
When enabling encryption of the config it is not possible to retrieve the encrypted values if the key is lost.
In a default installation of Curity the encryption key is not set. This means that the sensitive parts of the data are encrypted using a default key, and should be considered non-encrypted.
The first approach is to define a key when installing Curity. The installer.sh will ask if the configuration should be encrypted:
installer.sh
... Would you like to protect sensitive parts of the configuration with a unique encryption key? [y/N] y If you have an existing encryption key you want to use, paste it here (may be a comma separated list of keys); press enter to generate a new key
If you answer y to the question about encryption you are prompted with a second question where two options are available:
y
The key will be placed in <IDSVR_HOME>/etc/startup.properties after the installer is done:
<IDSVR_HOME>/etc/startup.properties
# Required: false CONFIG_ENCRYPTION_KEY="02b891b3ec501cece86de216a6f6a15f585dddcbd56fe21b410233d78dfaa79e"
It can be removed from this file and placed on the command line when starting Curity. See Defining Encryption Key on Startup.
Tip
The encryption key can be removed from startup.properties and given as a command line argument or an environment variable (by the same name) when starting Curity
startup.properties
Whenever configuration is added using REST, CLI or the Admin UI it will be encrypted using the new encryption key.
Instead of giving the configuration key as a property in startup.properties it’s also possible to provide it directly on the command line. When doing so, the entry in startup.properties is ignored.
$ idsvr --config-encryption-key 02b891b3ec501cece86de216a6f6a15f585dddcbd56fe21b410233d78dfaa79e
It’s also possible to provide multiple keys comma separated. The first key is used as the encryption key and primary decryption key, and all consecutive keys are used as decryption keys. This is handy when rotating keys or when migrating config between environments.
$ idsvr --config-encryption-key 02b891b3ec501cece86d,42b391bgecgg01cece
When it’s time to move to a production configuration, or when rotating keys, the bin/reenc tool can be used to re-encrypt the configuration.
bin/reenc
Fig. 191 Re-encrypting configuration
reenc
$ ./bin/reenc config.xml NEW_KEY OLD_KEY1,OLD_KEY2 > new-config.xml
In the same way, multiple “old” description keys can be given comma separated. The first argument is the current configuration, the second argument is the new encryption key and the last argument is a comma separated list of all old decryption keys.
The last key in the list is implicit and is the built in key. So the same script can be used to encrypt configuration that previously only was encrypted with the default key.
$ ./bin/reenc config.xml NEW_KEY > new-config.xml