13 Data at Rest Encryption #
The data at rest encryption features in SUSE OpenStack Cloud 9 include the barbican key management service for safely storing encryption keys, and cinder volume encryption. This topic explains how to configure a back end for barbican key storage, and how to configure cinder volumes to be encrypted.
The barbican service in SUSE OpenStack Cloud 9 supports two types of back ends for safely storing encryption keys:
A native database back end
An HSM device (KMIP + Micro Focus ESKM)
Configuring the key management back-end key store
Using the Cloud Lifecycle Manager reconfigure playbook, you can configure one of two back ends for the barbican key management service:
Native database: This is the default configuration in SUSE OpenStack Cloud 9.
KMIP + Atalla ESKM: For a KMIP device, an SSL client certificate is needed as HSM devices generally require two-way SSL for security reasons. You will need a client certificate, a client private key and client root certificate authority recognized by your HSM device.
13.1 Configuring KMIP and ESKM #
To configure KMIP + Atalla ESKM in place of the default database, begin by providing certificate information by modifying the sample configuration file,
barbican_kmip_plugin_config_sample.yml
, on the Cloud Lifecycle Manager node:~/openstack/ardana/ansible/roles/KEYMGR-API/files/samples/barbican_kmip_plugin_config_sample.yml
Copy this file to a temporary directory such as /tmp.
Edit the file to provide either client certificates as absolute file paths as shown below in bold, or by pasting certificate and key content directly into the file.
NoteFile paths take precedence over content variables if both are provided.
To set file path variables, open
kmip_plugin_certs.yml
for editing and set the paths to the cert files:vi /tmp/kmip_plugin_certs.yml # File paths takes precedence over cert content if both are provided. # Here file path refers to local filesystem path where ansible is # executed. client_cert_file_path: /path/to/cert/file client_key_file_path: /path/to/key/file client_cacert_file_path: /path/to/cacert/file
Alternatively, set the content variables by opening
/tmp/kmip_plugin_certs.yml
and copy the certificates and keys directly into the file.vi /tmp/kmip_plugin_certs.yml # Following are samples you need to replace with your # own content here or via file path approach mentioned above. client_cert_content: | -----BEGIN CERTIFICATE----- MIID0jCCArqgAwIBAgICAKQwDQYJKoZIhvcNAQELBQAwgZQxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDTzEUMBIGA1UEBxMLRnQuIENvbGxpbnMxGDAWBgNVBAoTD0hl ... d2xldHQgUGFja2FyZDEMMAoGA1UECxMDQ1RMMRYwFAYDVQQDFA1LTUlQX0xvY2Fs L7x0qB6Zaf3IBkOZqf5bMfAQoKfxww== -----END CERTIFICATE----- client_key_content: | -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEArjYVZzdsSMsk520UD1E94jl0/AZGLlsAB152dEP5E9C3mXzQ ZYvfApMh8PFc53gZwLBCb4joy1r8mZj/e7CwCUuo1cJHR9xnhwdK3RLeRbU3dfW8 ... 98DmYxBio8+wQWQdiAPRRthtnvhSWL67oYACPwvWUJJ+D18HfpWCEgCmBU3a8ZHc AaW8rRXtMZzuujGgAbA1hpf5z1lHuiG/X7/XMDVGiRALMyBbHV57 -----END RSA PRIVATE KEY----- client_cacert_content: | -----BEGIN CERTIFICATE----- MIIEmjCCA4KgAwIBAgIBADANBgkqhkiG9w0BAQsFADCBlDELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAkNPMRQwEgYDVQQHEwtGdC4gQ29sbGluczEYMBYGA1UEChMPSGV3 ... FAimEB/a2E+A0oxwuHmhMg0kOpDuXIWn4BW+Z6z5h1j3PFyg/CZ548Fz0XOgvXC7 Ejpkd+5R+24HloruUV1R2EYvmlr8UMFX80og11u+ -----END CERTIFICATE-----
Provide certificate information to the barbican service using the
barbican-reconfigure.yml
playbook:cd ~/openstack/ardana/ansible ansible-playbook -i hosts/verb_hosts barbican-reconfigure.yml -e@/tmp/kmip_plugin_certs.yml
Provide HSM connection credentials for the barbican service. In this step, provide the KMIP plug-in connection details to the barbican service: Open the file
barbican_deploy_config.yml
found here:~/openstack/ardana/ansible/roles/barbican-common/vars/barbican_deploy_config.yml
Set the value of
use_kmip_secretstore_plugin
toTrue
to use the KMIP plug-in orFalse
to use the default secret store plugin (store_crypto).Next, add KMIP client connection credentials and KMIP server hostname and port to
barbican_deploy_config.yml
:####################################################################### #################### KMIP Plugin Configuration Section ################ ####################################################################### # Flag to reflect whether KMIP plugin is to be used as back end for #storing secrets use_kmip_secretstore_plugin: True # Note: Connection username needs to match with 'Common Name' provided # in client cert request (CSR). barbican_kmip_username: userName barbican_kmip_password: password barbican_kmip_port: 1234 barbican_kmip_host: 111.222.333.444
Commit the changes to git:
cd ~/openstack/ardana/ansible git add -A git commit -m "My config"
and run the
barbican-reconfigure.yml
playbook in the deployment area:ansible-playbook -i hosts/localhost ready-deployment.yml cd ~/scratch/ansible/next/ardana/ansible ansible-playbook -i hosts/verb_hosts barbican-reconfigure.yml
13.2 Configuring Cinder Volumes for Encryption #
The data-at-rest encryption model in SUSE OpenStack Cloud provides support for encrypting cinder volumes (Volume Encryption). These encrypted volumes are protected with an encryption key that can be stored in an HSM appliance.
Assuming barbican and cinder services have been installed, you can configure a cinder volume type for encryption. Doing so will create a new cinder volume type, "LUKS," that can be selected when creating a new volume. Such volumes will be encrypted using a 256bit AES key:
source ~/service.osrc openstack role add --user admin --project admin cinder_admin openstack volume type create LUKS openstack volume type create \ --cipher aes-xts-plain64 --key_size 256 --control_location \ front-end LUKS nova.volume.encryptors.luks.LuksEncryptor +--------------------------------------+-------------------------------------------+-----------------+----------+------------------+ | Volume Type ID | Provider | Cipher | Key Size | Control Location | +--------------------------------------+-------------------------------------------+-----------------+----------+------------------+ | 99ed804b-7ed9-41a5-9c5e-e2002e9f9bb4 | nova.volume.encryptors.luks.LuksEncryptor | aes-xts-plain64 | 256 | front-end | +--------------------------------------+-------------------------------------------+-----------------+----------+------------------+
You should now be able to create a new volume with the type LUKS, which will request a new key from barbican. Once created, you can attach the new volume to an instance:
openstack volume create --display-name testVolumeEncrypted --volume-type LUKS --availability-zone nova 1
The volume list (openstack volume show
with the volume ID) should
now show that you have a new volume and that it is encrypted.
openstack volume show 2ebf610b-98bf-4914-aee1-9b866d7b1897 +---------------------------------------+--------------------------------------+ | Property | Value | +---------------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2016-03-04T00:17:45.000000 | | description | None | | encrypted | True | | id | 2ebf610b-98bf-4914-aee1-9b866d7b1897 | | metadata | {} | | migration_status | None | | multiattach | False | | name | testVolumeEncrypted | | os-vol-host-attr:host | ha-volume-manager@lvm-1#LVM_iSCSI | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 5f3b093c603f4dc8bc377d04e5385d42 | | os-volume-replication:driver_data | None | | os-volume-replication:extended_status | None | | replication_status | disabled | | size | 1 | | snapshot_id | None | | source_volid | None | | status | available | | user_id | 3bdde5491e174a8aafcbc5a88e01cac7 | | volume_type | LUKS | +---------------------------------------+--------------------------------------+
When using an ESKM appliance as the back end, you can also confirm that key operations are going to your HSM via its admin portal.
UUID Owner Object Type State Creation Date 8d54f41d-91dd-4f5e-bcfe-964af8213a8c barbican SymmetricKey PreActive 2016-03-02 13:58:58
13.3 For More Information #
For more information on data at rest security with ESKM, see Data Security Protection for SUSE OpenStack Cloud.