security-doc/security-guide/source/tenant-data/data-encryption.rst

Data encryption

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:

• Object Storage objects
• Network data

Volume encryption

A volume encryption feature in OpenStack supports privacy on a per-tenant basis. As of the Kilo release, the following features are supported:

• Creation and usage of encrypted volume types, initiated through the dashboard or a command line interface
  • Enable encryption and select parameters such as encryption algorithm and key size
• Volume data contained within iSCSI packets is encrypted
• Supports encrypted backups if the original volume is encrypted
• Dashboard indication of volume encryption status. Includes indication that a volume is encrypted, and includes the encryption parameters such as algorithm and key size
• Interface with the Key management service through a secure wrapper
  • Volume encryption is supported by back-end key storage for enhanced security (for example, a Hardware Security Module (HSM) or a KMIP server can be used as a Barbican back-end secret store)

Ephemeral disk encryption

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:

• Creation and usage of encrypted LVM ephemeral disks (note: At this time OpenStack Compute service only supports encrypting ephemeral disks in the LVM format)
  • The compute configuration, nova.conf, has the following default parameters within the "[ephemeral_storage_encryption]" section
    • option: 'cipher = aes-xts-plain64'
      • This field sets the cipher and mode used to encrypt ephemeral storage. AES-XTS is recommended by NIST specifically for disk storage, and the name is shorthand for AES encryption using the XTS encryption mode. Available ciphers depend on kernel support. At the command line, type 'cyrptsetup benchmark' to determine the available options (and see benchmark results), or go to /proc/crypto
    • option: 'enabled = false'
      • To use ephemeral disk encryption, set option: 'enabled = true'
    • option: 'key_size = 512'
      • Note that there may be a key size limitation from the backend key manager that could require the use of 'key_size = 256', which would only provide an AES key size of 128-bits. XTS requires it's own "tweak key" in addition to the encryption key AES requires. This is typically expressed as a single large key. In this case, using the 512-bit setting, 256 bits will be used by AES and 256 bits by XTS. (see NIST)
• Interface with the Key management service through a secure wrapper
  • Key management service will support data isolation by providing ephemeral disk encryption keys on a per-tenant basis
  • Ephemeral disk encryption is supported by back-end key storage for enhanced security (for example, an HSM or a KMIP server can be used as a barbican back-end secret store)
  • With the Key management service, when an ephemeral disk is no longer needed, simply deleting the key may take the place of overwriting the ephemeral disk storage area

Object Storage objects

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:

• Object content. For example, the content of an object PUT request’s body
• The entity tag (ETag) of objects that have non-zero content
• All custom user object metadata values. For example, metadata sent using X-Object-Meta- prefixed headers with PUT or POST requests

Any data or metadata not included in the list above are not encrypted, including:

• Account, container, and object names
• Account and container custom user metadata values
• All custom user metadata names
• Object Content-Type values
• Object size
• System metadata

For more information on the deployment, operation, or implementation of Object Storage encryption, see the swift Developer Documentation on Object Encryption.

Block Storage volumes and instance ephemeral filesystems

Block Storage supports a variety of mechanisms for supplying mountable volumes. The ability to encrypt volumes on the storage host depends on the service back ends chosen. Some back ends may not support this at all. It is outside the scope of this guide to specify recommendations for each Block Storage back-end driver.

For the purpose of performance, many storage protocols are unencrypted. Some protocols such as iSCSI can provide authentication and encrypted sessions, it is our recommendation to enable these features.

As both block storage and compute support LVM backed storage, we can easily provide an example applicable to both systems. In deployments using LVM, encryption may be performed against the backing physical volumes. An encrypted block device would be created using the standard Linux tools, with the LVM physical volume (PV) created on top of the decrypted block device using pvcreate. Then, the vgcreate or vgmodify tool may be used to add the encrypted physical volume to an LVM volume group (VG).

Network data

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.