The option exists for implementers to encrypt tenant data wherever it is stored on disk or transported over a network, such as the OpenStack volume encryption feature described below. This is above and beyond the general recommendation that users encrypt their own data before sending it to their provider.
The importance of encrypting data on behalf of tenants is largely related to the risk assumed by a provider that an attacker could access tenant data. There may be requirements here in government, as well as requirements per-policy, in private contract, or even in case law in regard to private contracts for public cloud providers. It is recommended that a risk assessment and legal consul advised before choosing tenant encryption policies.
Per-instance or per-object encryption is preferable over, in descending order, per-project, per-tenant, per-host, and per-cloud aggregations. This recommendation is inverse to the complexity and difficulty of implementation. Presently, in some projects it is difficult or impossible to implement encryption as loosely granular as even per-tenant. We recommend implementors make a best-effort in encrypting tenant data.
Often, data encryption relates positively to the ability to reliably destroy tenant and per-instance data, simply by throwing away the keys. It should be noted that in doing so, it becomes of great importance to destroy those keys in a reliable and secure manner.
Opportunities to encrypt data for users are present:
A volume encryption feature in OpenStack supports privacy on a per-tenant basis. As of the Kilo release, the following features are supported:
An ephemeral disk encryption feature addresses data privacy. The ephemeral disk is a temporary work space used by the virtual host operating system. Without encryption, sensitive user information could be accessed on this disk, and vestigial information could remain after the disk is unmounted. As of the Kilo release, the following ephemeral disk encryption features are supported:
nova.conf, has the following default parameters within the “[ephemeral_storage_encryption]” section
Object Storage (swift) supports the optional encryption of object data at rest on storage nodes. The encryption of object data is intended to mitigate the risk of users’ data being read if an unauthorized party were to gain physical access to a disk.
Encryption of data at rest is implemented by middleware that may be included in the proxy server WSGI pipeline. The feature is internal to a swift cluster and not exposed through the API. Clients are unaware that data is encrypted by this feature internally to the swift service; internally encrypted data should never be returned to clients through the swift API.
The following data are encrypted while at rest in swift:
X-Object-Meta-prefixed headers with PUT or POST requests
Any data or metadata not included in the list above are not encrypted, including:
For more information on the deployment, operation, or implementation of Object Storage encryption, see the swift Developer Documentation on Object Encryption.
When enabling the operating system, OpenStack Volume Encryption
performance can be enhanced by using the hardware acceleration features
currently available in both Intel and AMD processors. Both the OpenStack Volume
Encryption feature and the OpenStack Ephemeral Disk Encryption feature use
dm-crypt to secure volume data.
dm-crypt is a transparent disk
encryption capability in Linux kernel versions 2.6 and later. When the Volume
Encryption is enabled, encrypted data is sent over iSCSI to Block Storage,
securing data in transit and data at rest simultaneously. When using hardware
acceleration, the performance impact of both of the encryption features is
Although we recommend using the OpenStack Volume Encryption feature, Block Storage supports a large variety of alternative back-ends for supplying mountable volumes, and some of these may also provide volume encryption. Since there are so many back-ends, and since information from each vendor must be obtained, it is outside the scope of this guide to specify recommendations for implementing encryption in any of them.
Tenant data for compute could be encrypted over IPsec or other tunnels. This is not functionality common or standard in OpenStack, but is an option available to motivated and interested implementors.
Likewise, encrypted data will remain encrypted as it is transferred over the network.