Akshil Verma 39c5121c4c Encrypted volumes doc should use 256 bit key

The sample command uses a key size of 512 bits for an xts cipher.
While this is actually a valid key size and cipher for a typical
cryptsetup configuration, a key size of 512 bits does not play
nicely with the key managers, since generally they do not exceed
256 bits.

Changed the key from 512 to 256 becacuse standard key manager like
any of the production-ready key managers OpenStack uses, mostly do
not support 512 bit AES keys.

Change-Id: I795d28120f86fa22b2eaeee44c6dc5c4aa40c8c3
Closes-Bug: 1616239

2016-12-21 11:24:41 -06:00

5.8 KiB

Raw Blame History

Volume encryption supported by the key manager

We recommend the Key management service (barbican) for storing encryption keys used by the OpenStack volume encryption feature. It can be enabled by updating cinder.conf and nova.conf.

Initial configuration

Configuration changes need to be made to any nodes running the cinder-api or nova-compute server.

Steps to update cinder-api servers:

Edit the /etc/cinder/cinder.conf file to use Key management service as follows:
- Look for the [key_manager] section.
- Enter a new line directly below [key_manager] with the following:
```
api_class = castellan.key_manager.barbican_key_manager.BarbicanKeyManager
```
  Note
  
  Use a '#' prefix to comment out the line in this section that begins with 'fixed_key'.
Restart cinder-api.

Update nova-compute servers:

Ensure the cryptsetup utility is installed, and install the python-barbicanclient Python package.

Set up the Key Manager service by editing /etc/nova/nova.conf:

[key_manager]
api_class = castellan.key_manager.barbican_key_manager.BarbicanKeyManager

Restart nova-compute.

Create an encrypted volume type

Block Storage volume type assignment provides scheduling to a specific back-end, and can be used to specify actionable information for a back-end storage device.

This example creates a volume type called LUKS and provides configuration information for the storage system to encrypt or decrypt the volume.

Source your admin credentials:
```
$ . admin-openrc.sh
```
Create the volume type:
```
$ openstack volume type create LUKS
```

Mark the volume type as encrypted and provide the necessary details. Use --control_location to specify where encryption is performed: front-end (default) or back-end.

$ cinder encryption-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 |
+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+
| e64b35a4-a849-4c53-9cc7-2345d3c8fbde | nova.volume.encryptors.luks.LuksEncryptor | aes-xts-plain64 |   256    |    front-end     |
+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+

The OpenStack dashboard (horizon) supports creating the encrypted volume type as of the Kilo release. For instructions, see Create an encrypted volume type.

Create an encrypted volume

Use the OpenStack dashboard (horizon), or the cinder command to create volumes just as you normally would. For an encrypted volume, pass the --volume-type LUKS flag, which denotes that the volume will be of encrypted type LUKS. If that argument is left out, the default volume type, unencrypted, is used.

Source your admin credentials:
```
$ . admin-openrc.sh
```

Create an unencrypted 1 GB test volume:

$ openstack volume create --size 1 'unencrypted volume'

Create an encrypted 1 GB test volume:

$ openstack volume create --size 1 --type LUKS 'encrypted volume'

Notice the encrypted parameter; it will show True or False. The option volume_type is also shown for easy review.

Note

Due to the issue that some of the volume drivers do not set encrypted flag, attaching of encrypted volumes to a virtual guest will fail, because OpenStack Compute service will not run encryption providers.

Testing volume encryption

This is a simple test scenario to help validate your encryption. It assumes an LVM based Block Storage server.

Perform these steps after completing the volume encryption setup and creating the volume-type for LUKS as described in the preceding sections.

Create a VM:

$ openstack server create --image cirros-0.3.1-x86_64-disk --flavor m1.tiny TESTVM

Create two volumes, one encrypted and one not encrypted then attach them to your VM:

$ openstack volume create --size 1 'unencrypted volume'
$ openstack volume create --size 1 --type LUKS 'encrypted volume'
$ openstack volume list
$ openstack server add volume --device /dev/vdb TESTVM 'unencrypted volume'
$ openstack server add volume --device /dev/vdc TESTVM 'encrypted volume'

On the VM, send some text to the newly attached volumes and synchronize them:

# echo "Hello, world (unencrypted /dev/vdb)" >> /dev/vdb
# echo "Hello, world (encrypted /dev/vdc)" >> /dev/vdc
# sync && sleep 2
# sync && sleep 2

On the system hosting cinder volume services, synchronize to flush the I/O cache then test to see if your strings can be found:
```
# sync && sleep 2
# sync && sleep 2
# strings /dev/stack-volumes/volume-* | grep "Hello"
Hello, world (unencrypted /dev/vdb)
```

In the above example you see that the search returns the string written to the unencrypted volume, but not the encrypted one.

5.8 KiB Raw Blame History