
- Noted that python-barbicanclient is required by n-compute server - Change c-volume to c-api (missing from previous commit cca20b9) - Removed confusing section describing volume creation prior to volume type creation Closes-Bug: #1604096 Closes-Bug: #1604094 Change-Id: Ia7c8dfdb9d17949afbd1c8962facaa95ce8d5952
10 KiB
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
[keymgr]
section.Enter a new line directly below
[keymgr]
with the following:api_class = cinder.keymgr.barbican.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:
Install the
cryptsetup
utility and thepython-barbicanclient
Python package.Set up the Key Manager service by editing
/etc/nova/nova.conf
:[keymgr] api_class = nova.keymgr.barbican.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:
$ cinder type-create LUKS +--------------------------------------+-------+ | ID | Name | +--------------------------------------+-------+ | e64b35a4-a849-4c53-9cc7-2345d3c8fbde | LUKS | +--------------------------------------+-------+
Mark the volume type as encrypted and provide the necessary details. Use
--control_location
to specify where encryption is performed:front-end
(default) orback-end
.$ cinder encryption-type-create --cipher aes-xts-plain64 --key_size 512 \ --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 | 512 | 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:
$ cinder create --display-name 'unencrypted volume' 1 +--------------------------------+--------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | created_at | 2014-08-10T01:24:03.000000 | | description | None | | encrypted | False | | id | 081700fd-2357-44ff-860d-2cd78ad9c568 | | metadata | {} | | name | unencrypted volume | | os-vol-host-attr:host | controller | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 08fdea76c760475f82087a45dbe94918 | | size | 1 | | snapshot_id | None | | source_volid | None | | status | creating | | user_id | 7cbc6b58b372439e8f70e2a9103f1332 | | volume_type | None | +--------------------------------+--------------------------------------+
Create an encrypted 1 GB test volume:
$ cinder create --display-name 'encrypted volume' --volume-type LUKS 1 +--------------------------------+--------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | created_at | 2014-08-10T01:24:24.000000 | | description | None | | encrypted | True | | id | 86060306-6f43-4c92-9ab8-ddcd83acd973 | | metadata | {} | | name | encrypted volume | | os-vol-host-attr:host | controller | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 08fdea76c760475f82087a45dbe94918 | | size | 1 | | snapshot_id | None | | source_volid | None | | status | creating | | user_id | 7cbc6b58b372439e8f70e2a9103f1332 | | volume_type | LUKS | +--------------------------------+--------------------------------------+
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:
$ nova boot --flavor m1.tiny --image cirros-0.3.1-x86_64-disk vm-test
Create two volumes, one encrypted and one not encrypted then attach them to your VM:
$ cinder create --display-name 'unencrypted volume' 1 $ cinder create --display-name 'encrypted volume' --volume-type LUKS 1 $ cinder list +--------------------------------------+-----------+--------------------+------+-------------+----------+-------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+--------------------+------+-------------+----------+-------------+ | 64b48a79-5686-4542-9b52-d649b51c10a2 | available | unencrypted volume | 1 | None | false | | | db50b71c-bf97-47cb-a5cf-b4b43a0edab6 | available | encrypted volume | 1 | LUKS | false | | +--------------------------------------+-----------+--------------------+------+-------------+----------+-------------+ $ nova volume-attach vm-test 64b48a79-5686-4542-9b52-d649b51c10a2 /dev/vdb $ nova volume-attach vm-test db50b71c-bf97-47cb-a5cf-b4b43a0edab6 /dev/vdc
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.