diff --git a/cinder/interface/volume_driver.py b/cinder/interface/volume_driver.py index ad0d12d3f49..e3a7640c5e9 100644 --- a/cinder/interface/volume_driver.py +++ b/cinder/interface/volume_driver.py @@ -168,6 +168,10 @@ class VolumeDriverCore(base.CinderInterface): longer present, this call should succeed and allow Cinder to complete the process of deleting the volume. + It is imperative that this operation ensures that the data from the + deleted volume cannot leak into new volumes when they are created, as + new volumes are likely to belong to a different tenant/project. + :param volume: The volume to delete. :raises VolumeIsBusy: if the volume is still attached or has snapshots. VolumeBackendAPIException on error. diff --git a/cinder/volume/driver.py b/cinder/volume/driver.py index 10c90604252..f695b157dde 100644 --- a/cinder/volume/driver.py +++ b/cinder/volume/driver.py @@ -615,6 +615,10 @@ class BaseVD(object, metaclass=abc.ABCMeta): If volume_type extra specs includes 'replication: True' then the driver needs to delete the volume replica too. + + It is imperative that this operation ensures that the data from the + deleted volume cannot leak into new volumes when they are created, as + new volumes are likely to belong to a different tenant/project. """ return diff --git a/doc/source/admin/blockstorage-security.rst b/doc/source/admin/blockstorage-security.rst new file mode 100644 index 00000000000..26ba7f107f6 --- /dev/null +++ b/doc/source/admin/blockstorage-security.rst @@ -0,0 +1,75 @@ +======== +Security +======== + +Network traffic +~~~~~~~~~~~~~~~ + +Depending on your deployment's security requirements, you might be required to +encrypt network traffic. This can be accomplished with TLS. + +There are multiple deployment options, with the most common and recommended +ones being: + +- Only encrypt traffic between clients and public endpoints. This approach + results in fewer certificates to manage, and we refer to it as public TLS. + Public endpoints, in this sense, are endpoints only exposed to end-users. + Traffic between internal endpoints is not encrypted. + +- Leverages TLS for all endpoints in the entire deployment, including internal + endpoints of the OpenStack services and with auxiliary services such as the + database and the message broker. + +You can look at `TripleO's documentation on TLS`_ for examples on how to do +this. + +Cinder drivers should support secure TLS/SSL communication between the cinder +volume service and the backend, as configured by the ``driver_ssl_cert_verify`` +and ``driver_ssl_cert_path`` options in ``cinder.conf``. + +If unsure whether your driver supports TLS/SSL, please check the driver's +specific page in the :ref:`volume-drivers` page or contact the vendor. + +Data at rest +~~~~~~~~~~~~ + +Volumes' data can be secured at rest using Cinder's volume encryption feature. + +For encryption keys Cinder uses a Key management service, with Barbican being +the recommended service. + +More information on encryption can be found on the :ref:`volume-encryption` +section. + +Data leakage +~~~~~~~~~~~~ + +Some users and admins worry about data leakage between OpenStack projects or +users caused by a new volume containing partial or full data from a previously +deleted volume. + +These concerns are sometimes instigated by the ``volume_clear`` and +``volume_clear_size`` configuration options, but these options are only +relevant to the LVM driver, and only when using thick volumes (which are not +the default, thin volumes are). + +Writing data on a Cinder volume as a generic mechanism to prevent data leakage +is not implemented for other drivers because it does not ensure that the data +will be actually erased on the physical disks, as the storage solution could be +doing copy-on-write or other optimizations. + +Thin provisioned volumes return zeros for unallocated blocks, so we don't have +to worry about data leakage. As for thick volumes, each of the individual +Cinder drivers must ensure that data from a deleted volume can never leak to a +newly created volume. + +This prevents other OpenStack projects and users from being able to get data +from deleted volumes, but since the data may still be present on the physical +disks, somebody with physical access to the disks may still be able to retrieve +that data. + +For those concerned with this, we recommend using encrypted volumes or read +your storage solution's documentation or contact your vendor to see if they +have some kind of clear policy option available on their storage solution. + +.. _TripleO's documentation on TLS: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/tls-introduction.html diff --git a/doc/source/admin/index.rst b/doc/source/admin/index.rst index 40dd175176a..fa6520c32c1 100644 --- a/doc/source/admin/index.rst +++ b/doc/source/admin/index.rst @@ -24,6 +24,7 @@ Amazon EC2 Elastic Block Storage (EBS) offering. .. toctree:: :maxdepth: 1 + blockstorage-security.rst blockstorage-accelerate-image-compression.rst blockstorage-api-throughput.rst blockstorage-manage-volumes.rst diff --git a/doc/source/configuration/block-storage/volume-drivers.rst b/doc/source/configuration/block-storage/volume-drivers.rst index 84bd1e1bf2e..929f37fefac 100644 --- a/doc/source/configuration/block-storage/volume-drivers.rst +++ b/doc/source/configuration/block-storage/volume-drivers.rst @@ -1,3 +1,5 @@ +.. _volume-drivers: + ============== Volume drivers ============== diff --git a/doc/source/configuration/block-storage/volume-encryption.rst b/doc/source/configuration/block-storage/volume-encryption.rst index f15940b5b74..88d9098668c 100644 --- a/doc/source/configuration/block-storage/volume-encryption.rst +++ b/doc/source/configuration/block-storage/volume-encryption.rst @@ -1,3 +1,5 @@ +.. _volume-encryption: + ============================================== Volume encryption supported by the key manager ==============================================