Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 3. Encryption and Key Management

download PDF

The Red Hat Ceph Storage cluster typically resides in its own network security zone, especially when using a private storage cluster network.

Important

Security zone separation might 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:

  • SSH
  • SSL Termination
  • Messenger v2 protocol
  • Encryption in Transit
  • Encryption at Rest
  • Key rotation

3.1. SSH

All nodes in the Red Hat Ceph Storage cluster use SSH as part of deploying the cluster. This means that on each node:

  • A cephadm user exists with password-less root privileges.
  • The SSH service is enabled and by extension port 22 is open.
  • A copy of the cephadm user’s public SSH key is available.
Important

Any person with access to the cephadm user by extension has permission to run commands as root on any node in the Red Hat Ceph Storage cluster.

Additional Resources

  • See the How cephadm works section in the Red Hat Ceph Storage Installation Guide for more information.

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 versions 2 and 3 use Civetweb. Earlier versions of Civetweb do not support SSL and later versions support SSL with some performance limitations.

The object gateway Red Hat Ceph Storage version 5 uses Beast. You can configure the Beast front-end web server to use the OpenSSL library to provide Transport Layer Security (TLS).

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.

See Configuring SSL for Beast and HAProxy and keepalived for details.

3.3. Messenger v2 protocol

The second version of Ceph’s on-wire protocol, msgr2, has the following features:

  • A secure mode encrypting all data moving through the network.
  • Encapsulation improvement of authentication payloads, enabling future integration of new authentication modes.
  • Improvements to feature advertisement and negotiation.

The Ceph daemons bind to multiple ports allowing both the legacy v1-compatible, and the new, v2-compatible Ceph clients to connect to the same storage cluster. Ceph clients or other Ceph daemons connecting to the Ceph Monitor daemon uses the v2 protocol first, if possible, but if not, then the legacy v1 protocol is used. By default, both messenger protocols, v1 and v2, are enabled. The new v2 port is 3300, and the legacy v1 port is 6789, by default.

The messenger v2 protocol has two configuration options that control whether the v1 or the v2 protocol is used:

  • ms_bind_msgr1 - This option controls whether a daemon binds to a port speaking the v1 protocol; it is true by default.
  • ms_bind_msgr2 - This option controls whether a daemon binds to a port speaking the v2 protocol; it is true by default.

Similarly, two options control based on IPv4 and IPv6 addresses used:

  • ms_bind_ipv4 - This option controls whether a daemon binds to an IPv4 address; it is true by default.
  • ms_bind_ipv6 - This option controls whether a daemon binds to an IPv6 address; it is true by default.
Note

The ability to bind to multiple ports has paved the way for dual-stack IPv4 and IPv6 support.

The msgr2 protocol supports two connection modes:

  • crc

    • Provides strong initial authentication when a connection is established with cephx.
    • Provides a crc32c integrity check to protect against bit flips.
    • Does not provide protection against a malicious man-in-the-middle attack.
    • Does not prevent an eavesdropper from seeing all post-authentication traffic.

  • secure

    • Provides strong initial authentication when a connection is established with cephx.
    • Provides full encryption of all post-authentication traffic.
    • Provides a cryptographic integrity check.

The default mode is crc.

Ceph Object Gateway Encryption

Also, the Ceph Object Gateway supports encryption with customer-provided keys using its S3 API.

Important

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

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.

Important

To comply with regulatory compliance standards requiring strict encryption in transit, system administrators MUST use dmcrypt for RBD Cinder to ensure on-wire encryption within the Ceph storage cluster.

Additional resources

3.4. Encryption in transit

Starting with Red Hat Ceph Storage 5 and later, encryption for all Ceph traffic over the network is enabled by default, with the introduction of the messenger version 2 protocol. The secure mode setting for messenger v2 encrypts communication between Ceph daemons and Ceph clients, providing end-to-end encryption.

You can check for encryption of the messenger v2 protocol with the ceph config dump command, netstat -Ip | grep ceph-osd command, or verify the Ceph daemon on the v2 ports.

Additional resources

3.5. Compression modes of messenger v2 protocol

The messenger v2 protocol supports the compression feature. Compression is not enabled by default.

Compressing and encrypting the same message is not recommended as the level of security of messages between peers is reduced. If encryption is enabled, a request to enable compression is ignored until the configuration option ms_osd_compress_mode is set to true.

It supports two compression modes:

  • force

    • In multi-availability zones deployment, compresses replication messages between OSDs saves latency.
    • In the public cloud, minimizes message size, thereby reducing network costs to cloud provider.
    • Instances on public clouds with NVMe provides low network bandwidth relative to the device bandwidth. Does not provide protection against a malicious man-in-the-middle attack.

  • none

    • The messages are transmitted without compression.

To ensure that compression of the message is enabled, run the debug_ms command and check some debug entries for connections. Also, you can run the ceph config get command to get details about the different configuration options for the network messages.

Additional resources

3.6. Encryption at Rest

Red Hat Ceph Storage supports encryption at rest in a few scenarios:

  1. Ceph Storage Cluster: The Ceph Storage Cluster supports Linux Unified Key Setup or LUKS encryption of Ceph 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, or a custom application built on librados.
  2. Ceph Object Gateway: The Ceph storage cluster supports encryption of client objects. When the Ceph Object Gateway encrypts objects, they are encrypted independently of the Red Hat 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 in Ceph OSDs. Red Hat Ceph Storage 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. It can 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 dmcrypt_key.

Important

System administrators must explicitly enable encryption.

By default, Ceph does not encrypt data stored in Ceph OSDs. System administrators must enable dmcrypt to encrypt data stored in Ceph OSDs. When using a Ceph Orchestrator service specification file for adding Ceph OSDs to the storage cluster, set the following option in the file to encrypt Ceph OSDs:

Example

...
encrypted: true
...

Note

LUKS and 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.

Additional Resources

3.7. Enabling key rotation

Ceph and Ceph Object Gateway daemons within the Ceph cluster have a secret key. This key is used to connect to and authenticate with the cluster. You can update an active security key within an active Ceph cluster with minimal service interruption, by using the key rotation feature.

Note

The active Ceph cluster includes nodes within the Ceph client role with parallel key changes.

Key rotation helps ensure that current industry and security compliance requirements are met.

Prerequisites

  • A running Red Hat Ceph Storage cluster.
  • User with admin privileges.

Procedure

  1. Rotate the key:

    Syntax

    ceph orch daemon rotate-key NAME

    Example

    [ceph: root@host01 /]# ceph orch daemon rotate-key mgr.ceph-key-host01
Scheduled to rotate-key mgr.ceph-key-host01 on host 'my-host-host01-installer'

  2. If using a daemon other than MDS, OSD, or MGR, restart the daemon to switch to the new key. MDS, OSD, and MGR daemons do not require daemon restart.

    Syntax

    ceph orch restart SERVICE_TYPE

    Example

    [ceph: root@host01 /]# ceph orch restart rgw

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.