Chapter 3. Encryption and Key Management
The Ceph Storage cluster typically resides in its own network security zone—especially the cluster network. In a typical deployment all traffic transmitted over public networks between the Ceph client and the Ceph Storage cluster and all traffic transmitted between Ceph daemons over the cluster network IS authenticated but NOT encrypted.
Security zone separation may be insufficient for protection if an attacker gains access to Ceph clients on the public network.
There are situations where there is a security requirement to assure the confidentiality or integrity of network traffic, and where Red Hat Ceph Storage uses encryption and key management, including:
- SSL Termination
- Encryption in Transit
- Encryption at Rest
All nodes in the RHCS cluster use SSH as part of deploying the cluster. This means that on each node:
- An Ansible user exists with password-less root privileges.
- The SSH service is enabled and by extension port 22 is open.
- A copy of the Ansible user’s public SSH key is available.
Any person with access to the Ansible user by extension has permission to exercise CLI commands as root on any node in the RHCS cluster.
3.2. SSL Termination
The Ceph Object Gateway may be deployed in conjunction with HAProxy and
keepalived for load balancing and failover. The object gateway Red Hat Ceph Storage version 2 and 3 uses Civetweb. Earlier versions of Civetweb do not support SSL and later versions support SSL with some performance limitations. When using HAProxy and
keepalived to terminate SSL connections, the HAProxy and
keepalived components use encryption keys.
When using HAProxy and
keepalived to terminate SSL, the connection between the load balancer and the Ceph Object Gateway is NOT encrypted.
3.3. Encryption in Transit
In Red Hat Ceph Storage 3.1 and earlier releases, data transmitted between OSDs is NOT encrypted, unless data is encrypted on the client.
Ceph Object Gateway Encryption
As noted in Section 3.2, “SSL Termination”, in Red Hat Ceph Storage 3.1 and earlier releases Ceph Object Gateway terminates an SSL connection at the load balancer. The Ceph Object Gateway supports encryption with customer-provided keys using its S3 API. See S3 API Encryption for details.
To comply with regulatory compliance standards requiring strict encryption in transit, administrators MUST deploy the Ceph Object Gateway with client-side encryption.
Ceph Block Device Encryption
In Red Hat Ceph Storage 3.1 and earlier releases, the Ceph Block Device DOES NOT provide encryption of block devices. This means that data sent between the block device
rbd client and the OSDs is NOT encrypted unless it is encrypted at the client first. System administrators integrating Ceph as a backend for Red Hat OpenStack Platform 13 MUST encrypt Ceph Block Device volumes using
dm_crypt for RBD Cinder to ensure on-wire encryption within the Ceph Storage cluster.
To comply with regulatory compliance standards requiring strict encryption in transit, administrators MUST use
dmcrypt for RBD Cinder to ensure on-wire encryption within the Ceph Storage Cluster.
3.4. Encryption at Rest
Red Hat Ceph Storage supports encryption at rest in a few scenarios:
Ceph Storage Cluster: The Ceph Storage Cluster supports Linux Unified Key Setup or LUKS encryption of OSDs and their corresponding journals, write-ahead logs, and metadata databases. In this scenario, Ceph will encrypt all data at rest irrespective of whether the client is a Ceph Block Device, Ceph Filesystem, Ceph Object Storage cluster or a custom application built on
- Ceph Object Gateway: The Ceph Storage Cluster supports encryption of client objects. When the Ceph Object Gateway encrypts objects, they are encrypted indepdently of the Ceph Storage Cluster. Additionally, the data transmitted is between the Ceph Object Gateway and the Ceph Storage Cluster is in encrypted form.
Ceph Storage Cluster Encryption
The Ceph Storage Cluster supports encrypting data stored on OSDs. RHCS can encrypt logical volumes with
lvm by specifying
dmcrypt; that is,
lvm, invoked by
ceph-volume, encrypts an OSD’s logical volume not its physical volume, and may encrypt non-LVM devices like partitions using the same OSD key. Encrypting logical volumes allows for more configuration flexibility.
Ceph uses LUKS v1 rather than LUKS v2, because LUKS v1 has the broadest support among Linux distributions.
When creating an OSD,
lvm will generate a secret key and pass the key to the Ceph monitors securely in a JSON payload via
stdin. The attribute name for the encryption key is
System administrators must explicitly enable encryption.
By default, Ceph does not encrypt data stored in OSDs. System administrators must enable
dmcrypt in Ceph Ansible. See Installation: Step 5, ii for details on setting the
dmcrypt option in the
dmcrypt only address encryption for data at rest, not encryption for data in transit.
Ceph Object Gateway Encryption
The Ceph Object Gateway supports encryption with customer-provided keys using its S3 API. When using customer-provided keys, the S3 client passes an encryption key along with each request to read or write encrypted data. It is the customer’s responsibility to manage those keys. Customers must remember which key the Ceph Object Gateway used to encrypt each object.
See S3 API Encryption for details.