Menu Close
Settings Close

Language and Page Formatting Options

Chapter 1. Introduction

Security is an important concern and should be a strong focus of any Red Hat Ceph Storage deployment. Data breaches and downtime are costly and difficult to manage, laws may require passing audits and compliance processes, and projects have an expectation of a certain level of privacy and security of their data. This document provides a general introduction to security for Red Hat Ceph Storage, as well as the role of Red Hat in supporting your system’s security.

1.1. Preface

This document provides advice and good practice information for hardening the security of your Red Hat Ceph Storage deployment, with a focus on Ceph Ansible-based deployments. While following the instructions in this guide will help harden the security of your environment, we do not guarantee security or compliance from following these recommendations.

1.2. Introduction to RHCS

Red Hat Ceph Storage (RHCS) is a highly scalable and reliable object storage solution, which is typically deployed in conjunction with cloud computing solutions like OpenStack, as a standalone storage service, or as network attached storage using interfaces such as iSCSI.

All RHCS deployments consist of a storage cluster commonly referred to as the Ceph Storage Cluster or RADOS (Reliable Autonomous Distributed Object Store), which consists of three types of daemons:

  • Ceph Monitors (ceph-mon): Ceph monitors provide a few critical functions: first, they establish agreement about the state of the cluster; second, they maintain a history of the state of the cluster, such as whether an OSD is up and running and in the cluster; third, they provide a list of pools through which clients write and read data; and finally, they provide authentication for clients and the Ceph Storage Cluster daemons.
  • Ceph Managers (ceph-mgr): Ceph manager daemons track the status of peering between copies of placement groups distributed across Ceph OSDs, a history of the placement group states, and metrics about the Ceph cluster. They also provide interfaces for external monitoring and management systems.
  • Ceph OSDs (ceph-osd): Ceph Object Storage Daemons (OSDs) store and serve client data, replicate client data to secondary Ceph OSD daemons, track and report to Ceph Monitors on their health and on the health of neighboring OSDs, dynammically recover from failures and backfill data when the cluster size changes, among other functions.

All RHCS deployments store end-user data in the Ceph Storage Cluster or RADOS (Reliable Autonomous Distributed Object Store). Generally, end users DO NOT interact with the Ceph Storage Cluster directly. Rather, they interact with a Ceph client. There are three primary Ceph Storage Cluster clients:

  • Ceph Object Gateway (ceph-radosgw): The Ceph Object Gateway—​also known as RADOS Gateway, radosgw or rgw--provides an object storage service with RESTful APIs. Ceph Object Gateway stores data on behalf of its clients in the Ceph Storage Cluster or RADOS.
  • Ceph Block Device (rbd): The Ceph Block Device provides copy-on-write, thin-provisioned and cloneable virtual block devices to a Linux kernel via Kernel RBD (krbd) or to cloud computing solutions like OpenStack via librbd.
  • Ceph Filesystem (cephfs): The Ceph Filesystem consists of one or more Metadata Servers (mds), which store the inode portion of a fileystem as objects on the Ceph Storage Cluster. Ceph filesystems can be mounted via a kernel client, a FUSE client, or via the libcephfs library for cloud computing solutions like OpenStack.

Additional clients include librados, which enables developers to create custom applications to interact with the Ceph Storage cluster, and command line interface clients for administrative purposes.

1.3. Supporting Software

An important aspect of Red Hat Ceph Storage security is to deliver solutions that have security built-in upfront and that Red Hat supports over time. Specific steps which Red Hat takes with Red Hat Ceph Storage include:

  • Maintaining upstream relationships and community involvement to help focus on security from the start.
  • Selecting and configuring packages based on their security and performance track records.
  • Building binaries from associated source code (instead of simply accepting upstream builds).
  • Applying a suite of inspection and quality assurance tools to prevent an extensive array of potential security issues and regressions.
  • Digitally signing all released packages and distributing them through cryptographically authenticated distribution channels.
  • Providing a single, unified mechanism for distributing patches and updates.

In addition, Red Hat maintains a dedicated security team that analyzes threats and vulnerabilities against our products, and provides relevant advice and updates through the Customer Portal. This team determines which issues are important, as opposed to those that are mostly theoretical problems. The Red Hat Product Security team maintains expertise in, and makes extensive contributions to the upstream communities associated with our subscription products. A key part of the process, Red Hat Security Advisories, deliver proactive notification of security flaws affecting Red Hat solutions–along with patches that are frequently distributed on the same day the vulnerability is first published.