Configuring encryption using off-server encryption keys  

Configure KMIP (Key Management Interoperability Protocol) encryption to use encryption keys that are stored on another server.

Configure KMIP (Key Management Interoperability Protocol) encryption to use encryption keys that are stored on another server. In addition to encrypting table data, you can optionally encrypt passwords in configuration files and sensitive information in system tables.

The entire cluster uses the system key to decrypt SSTables for operations such as repair. You also use the system key during upgrading and restoring SSTables that might have been corrupted.

The location of the dse.yaml file depends on the type of installation:
Installer-Services /etc/dse/dse.yaml
Package installations /etc/dse/dse.yaml
Installer-No Services install_location/resources/dse/conf/dse.yaml
Tarball installations install_location/resources/dse/conf/dse.yaml
Use OpsCenter to configure an alert to monitor KMIP server status.

Procedure

  1. Back up SSTables.
  2. Set the system_key_directory.
  3. Set permissions on the system_key_directory to give rights to change the keytab file only to the user/group running DataStax Enterprise. JNA takes care of setting these permissions.
  4. Ensure that the user who encrypts data has been granted ALTER permission on the table that contains the data to be encrypted. You can use LIST PERMISSIONS to view the permissions that are granted to a user.
  5. Perform host configuration for one or more KMIP key server groups.
    1. Configure the KMIP key manager and authorize each DataStax Enterprise node to the KMIP key server group. Consult the KMIP key server documentation.
    2. On each DataStax Enterprise node, open the dse.yaml file in a text editor and configure the KMIP key server group or key server groups in the kmip_hosts section. Configure options for a kmip_groupname section for each KMIP key server or group of KMIP key servers. Using separate key server configuration settings allows use of different key servers to encrypt table data, and eliminates the need to enter key server configuration information in DDL statements and other configurations.
    Option Description
    hosts A comma-separated list of hosts[:port] for the KMIP key server. There is no load balancing. In failover scenarios, failover occurs in the same order that servers are listed. For example: hosts: kmip1.yourdomain.com, kmip2.yourdomain.com
    keystore_path The path to a java keystore that identifies the DSE node to the KMIP key server. For example: /path/to/keystore.jks
    keystore_type The type of key store. The default value is jks.
    keystore_password The password to access the key store.
    truststore_path The path to a java truststore that identifies the KMIP key server to the DataStax Enterprise node. For example: /path/to/truststore.jks
    truststore_type The type of trust store. The default value is jks.
    truststore_password The password to access the trust store.
    key_cache_millis Milliseconds to locally cache the encryption keys that are read from the KMIP hosts. The longer the encryption keys are cached, the fewer requests are made to the KMIP key server, but the longer it takes for changes, like revocation, to propagate to the DSE node. Default: 300000.
    timeout Socket timeout in milliseconds. Default: 1000.
    This example shows configuration settings for Vormetric and Thales key servers:
    kmip_hosts:  
      vormetricgroup:
        hosts: vormetric1.mydomain.com, vormetric2.mydomain.com, vormetric3.mydomain.com 
        keystore_path: pathto/kmip/keystore.jks
        keystore_type: jks
        keystore_password: password
        truststore_path: pathto/kmip/truststore.jks
        truststore_type: jks
        truststore_password: password
        
      thalesgroup:
        hosts: thales1.mydomain.com, thales2.mydomain.com
        keystore_path: pathto/kmip/keystore.jks 
        keystore_type: jks
        keystore_password: password
        truststore_path: pathto/kmip/truststore.jks 
        truststore_type: jks
        truststore_password: password
  6. On each DataStax Enterprise node, confirm communication with the KMIP key server and restart the node.
    1. Use the dsetool utility to confirm communication.
      $ dsetool managekmip list kmip_groupname
    2. After communication between the DataStax Enterprise node and the KMIP key server or servers is verified, restart the node. Repeat this step on each node.
      The DataStax Enterprise node will not start if it is unable to connect to the configured KMIP key server.
  7. Set and use KMIP as the encryption key provider.
    1. Set KMIP encryption options when you create a table or alter an existing table.
    2. Optional: Configure password encryption to encrypt stored passwords in the configuration files. Use dsetool to generate the required URL:
      $ dsetool createsystemkey 'AES/ECB/PKCS5' 128 -k kmip_hosts_value
      Edit the dse.yaml file in a text editor. For the config_encryption_key_name property, paste the URL that is returned from the dsetool createsystemkey utility. See Encrypting sensitive property values.
    3. Optional: Configure system table encryption to encrypt system tables that contain sensitive information. Edit the dse.yaml file in a text editor. In the system_info_encryption section, comment out key_name, and uncomment or add key_provider and kmip_host:
      system_info_encryption:   
        enabled: false
        cipher_algorithm: AES
        secret_key_strength: 128
        chunk_length_kb: 64
        #key_name: system_table_keytab
        key_provider: KmipKeyProviderFactory
        kmip_host: <kmip_groupname>

      Use key_provider: KmipKeyProviderFactory only to specify a KMIP key server.

  8. Restart the cluster.
  9. Encrypt data on a per table basis. See Encrypting table data with KMIP encryption keys.
  10. Rewrite all SSTables using nodetool upgradesstables --include-all-sstables to immediately store the tables on disk.
  11. After encrypted SSTables are flushed to disk, you can verify that the dse_system keyspace and encrypted_keys table exist:
    cqlsh:mykeyspace> DESCRIBE KEYSPACES;
    
    system  dse_system  mykeyspace  system_traces

    On all nodes, the system key appears when selected from the dse_system.encrypted_keys table:

    cqlsh:mykeyspace> SELECT * FROM dse_system.encrypted_keys;
     
    key_file   | cipher | strength | key_id        | key
    -----------+--------+----------+---------------+-----------
    system_key |    AES |      128 | 2e4ea4a0-... | uyBEGhX...