Encryption at rest with Ceph

Do you have a big data center? Do you have terabytes of confidential data stored in that data center? Are you worried that your data might be exposed to malicious attacks? One of the most prominent security features of storage solutions is encryption at rest. This blog will explain this in more detail and how it is implemented in Charmed Ceph, Canonical’s software-defined storage solution.

What is data at rest?

Before we dive into encryption, we need to define what data at rest is. There are three states for digital data: data in use, data in transit and data at rest. Data in use refers to active data stored in non-persistent volumes, typically RAM or CPU caches. Data in transit is the state where data is transferred over a network, either private or public. Data at rest means inactive data that is stored physically on persistent storage, i.e. disks, databases, data warehouses, mobile devices, archives, etc. When at rest, data can be subject to malicious threats such as data theft or data corruption by obtaining physical access to the storage hardware. There are multiple security measures to protect data at rest, starting from password protection, federation and data encryption.

What is data encryption at rest?

Encryption at rest is the encoding of data when it is persisted. It is designed to prevent the attacker from accessing unencrypted data by ensuring all raw data is encrypted when stored on a persistent device. 

Encryption at rest addresses a multitude of potential threats. Starting from the lowest threat level like the theft of an HDD device, server loss, up to extremes such as the compromise of an entire rack of servers or the entire data center, businesses will have peace of mind as long as the stolen data was encrypted. The attacker could still get physical access to the storage, but without the encryption keys, it is significantly more complex and resource-consuming to read the encrypted data.

Nowadays, most businesses are interested in data security, especially after the introduction of GDPR. Some also need to comply with industry and government regulations such as HIPAA, PCI-DSS and FedRAMP. Encryption at rest is a prerequisite for some of those regulations and Canonical’s security certification program can help your business stay compliant.

How does encryption at rest work?

Encryption of data on block storage in a Linux environment is quite straightforward. The Ubuntu kernel supports the dm-crypt and LUKS utilities, for transparent disk encryption and on-disk encryption key management respectively. However, encryption at rest also requires a key management solution (KMS) to ensure the security of the encryption keys and proper role-based access control (RBAC) definitions. 

Ceph encryption at rest

Charmed Ceph supports encryption at rest out-of-the-box both as part of an OpenStack private cloud deployment and as a standalone storage solution. Charmed Ceph is based on a model-driven approach. All Ceph components are wrapped in charms, that is, code that drives lifecycle management automation.

For Ceph encryption at rest, the selected KMS is Hashicorp Vault. Vault is a widely used Encryption-as-a-Service solution that supports centralised key management and key rotation to ensure cryptographic best practices. When booting up, Vault needs to be unsealed in order for services to connect to it and read their encryption keys. Unsealing Vault requires a Master encryption key that needs a number of unseal keys to be unlocked. After initialising Vault, the data center operations team needs to provide a token retrieved from Vault to establish a connection between the Ceph charms and Vault.

Charmed Ceph uses Vaultlocker as an integration component between dm-crypt and Vault. Vaultlocker ensures the encryption keys are only ever held in memory locally and stored persistently in Vault, only to be read from Vault into memory during any subsequent operation, such as unlocking or encryption of a block device.

RBAC is implemented through the Vault charm. The charms use Vault AppRoles to handle communication between Vault and the Ceph cluster. Every storage server of the Ceph cluster has a specific AppRole (consisting of a role ID and secret) which can only be used from a specific IP address.

If all of the above sounds fairly complicated, it is mostly because Canonical ensures that the attack surface for Charmed Ceph is the smallest possible. Using Vault and Vaultlocker, Charmed Ceph has a solid approach to data encryption at rest to protect against all possible types of physical device loss in your data center.

Learn more about Charmed Ceph or contact us about your data center storage needs.

Read our Charm Deployment Guide sections on using Vault and encryption-at-rest.