Applies to SUSE OpenStack Cloud 9

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.
Note
File paths take precedence over content variables if both are provided.

To set file path variables, open kmip_plugin_certs.ymlfor 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 to True to use the KMIP plug-in or False 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.