Storage security

The Block Storage service (cinder) provides data security through the Key Manager service (barbican). The Block Storage service uses a one-to-one, key to volume mapping with the key managed by the Key Manager service. You define the encryption type when configuring the volume type.

Security can also be improved at the backend level by encrypting control and/or data traffic. For example, with Red Hat Ceph Storage, you can achieve this by enabling messengerv2 secure mode. This way, network traffic among Ceph services and from OpenStack compute nodes is encrypted.

You configure object and container security at the service and node level. The Object Storage service (swift) provides no native encryption for containers and objects. However, with the Key Manager service enabled, the Object Storage service can transparently encrypt and decrypt your stored (at-rest) objects. At-rest encryption is distinct from in-transit encryption in that it refers to the objects being encrypted while being stored on disk.

The Shared File Systems service (manila) can secure shares through access restriction, whether by instance IP, user or group, or TLS certificate. Some Shared File Systems service deployments can feature separate share servers to manage the relationship between share networks and shares. Some share servers support, or even require, additional network security. For example, a CIFS share server requires the deployment of an LDAP, Active Directory, or Kerberos authentication service.

Some backends also support encrypting the data AT REST. This enables extra security by encrypting the backend disks themselves, preventing physical security threats such as theft or unwiped recycled disks.

For more information about configuring security options for the Block Storage service, Object Storage service, and Shared File Systems service, see Harden the deployment.