データのセキュリティーおよび強化ガイド

Red Hat Ceph Storage 4

Red Hat Ceph Storage データのセキュリティーおよび強化ガイド

Red Hat Ceph Storage Documentation Team

概要

本書では、Ceph Storage クラスターおよびそのクライアントのデータセキュリティーと強化情報を提供します。

第1章 はじめに

セキュリティーは重要な問題であり、Red Hat Ceph Storage デプロイメントに重点を置きます。データ違反やダウンタイムはコストがかかり、管理が困難であり、法では監査およびコンプライアンスプロセスを通過する必要があり、プロジェクトはデータの特定レベルのプライバシーとセキュリティーを期待しています。本書では、Red Hat Ceph Storage のセキュリティーの概要と、システムのセキュリティーをサポートする Red Hat のロールについて説明します。

1.1. 前書き

本書では、Ceph Ansible ベースのデプロイメントを中心に、Red Hat Ceph Storage デプロイメントのセキュリティーを強化するためのアドバイスと適切なプラクティスについて説明します。本ガイドの手順に従うと、お使いの環境のセキュリティーが強化されますが、この推奨事項に従ってセキュリティーやコンプライアンスは保証されません。

1.2. RHCS の概要

Red Hat Ceph Storage(RHCS)は高度にスケーラブルで信頼性の高いオブジェクトストレージソリューションです。これは通常、OpenStack などのクラウドコンピューティングソリューションと共にデプロイされます。スタンドアロンのストレージサービスとして、または iSCSI 等のインターフェースを使用してネットワーク接続ストレージとしてデプロイされます。

すべての RHCS デプロイメントは、一般的に Ceph Storage Cluster または RADOS(Reliable Aural Distributed Object Store)と呼ばれ、3 種類のデーモンで構成されます。

  • Ceph Monitors (ceph-mon): Ceph モニターは重要な機能を提供しています。まずは、クラスターの状態に関する合意が確立され、2 番目に、OSD が稼働しているかどうかやクラスター内での履歴を維持します。3 つ目は、どのクライアントがデータの書き込みと読み取りを行うプールの一覧を提供します。最後に、クライアントと Ceph Storage Cluster デーモンの認証を提供します。
  • Ceph Manager (ceph-mgr): Ceph Manager デーモンは、Ceph OSD 全体に分散される配置グループのコピー間のピアングのステータス、配置グループの状態履歴、Ceph クラスターに関するメトリックを追跡します。また、外部監視と管理システムのインターフェースも提供します。
  • Ceph OSD (ceph-osd): Ceph Object Storage Daemons (OSD) は、クライアントデータの保存と提供、クライアントデータのセカンダリー Ceph OSD デーモンへのレプリケート、その健全性と隣接する OSD の健全性の追跡と Ceph Monitor への報告、障害からの動的リカバリー、クラスタサイズの変更時のデータのバックフィルなどの機能を備えています。

すべての RHCS デプロイメントでは、エンドユーザーデータを Ceph Storage Cluster または RADOS(Reliable A former Distributed Object Store)に保存します。一般的に、エンドユーザーは Ceph Storage クラスターと直接対話しないでください。代わりに、Ceph クライアントと対話します。Ceph Storage Cluster には、主に 3 つの主要クライアントがあります。

  • Ceph Object Gateway (ceph-radosgw): Ceph Object Gateway は、RADOS Gateway (radosgw または rgw) とも呼ばれており、RESTful API でオブジェクトストレージサービスを提供します。Ceph Object Gateway は、クライアントの代わりに Ceph Storage クラスターまたは RADOS にデータを保管します。
  • Ceph Block Device (rbd): Ceph ブロックデバイスは、Kernel RBD (krbd) を介して Linux カーネル、または librbd を介して OpenStack といったクラウドコンピューティングソリューションに、コピーオンライト、シンプロビジョニング、およびクローン可能な仮想ブロックデバイスを提供します。
  • Ceph Filesystem (cephfs): Ceph Filesystem は、1 つ以上のメタデータサーバー (mds) で構成されており、このファイルシステムの inode の部分を Ceph Storage クラスターのオブジェクトとして格納します。Ceph ファイルシステムは、カーネルクライアント、FUSE クライアント、または OpenStack などのクラウドコンピューティングソリューション向けに libcephfs ライブラリーを介してマウントすることができます。

追加のクライアントには、開発者がカスタムアプリケーションを作成して Ceph Storage クラスターと対話できる librados や、管理目的でコマンドラインインターフェースクライアントなどがあります。

1.3. ソフトウェアのサポート

Red Hat Ceph Storage セキュリティーの重要な要素として、Red Hat が一定期間にわたってサポートしているセキュリティーの組み込み前と、そのソリューションを提供することが挙げられます。Red Hat が Red Hat Ceph Storage で実施する特定のステップには、以下が含まれます。

  • アップストリームの関係とコミュニティーの関心を維持することで、開始からセキュリティーに重点を置いています。
  • セキュリティーおよびパフォーマンス追跡レコードに基づいてパッケージを選択および設定する。
  • 関連付けられたソースコードからバイナリーをビルドします(アップストリームビルドを許可する代わりに)。
  • インスペクションおよび品質保証ツールのスイートを適用して、潜在的なセキュリティー問題およびリグレッションの多数の配列を防ぎます。
  • リリースされたすべてのパッケージをデジタル署名し、暗号で認証されたディストリビューションチャンネルを介して配布します。
  • パッチと更新を配布するための単一の統合メカニズムを提供します。

さらに、Red Hat は、製品の脅威と脆弱性を分析し、カスタマーポータルを通じて適切なアドバイスと更新を提供する専用のセキュリティーチームを提供しています。このチームは、多くの理論上の問題とは対照的に、重要な問題を判断します。Red Hat Product Security チームは専門知識を維持しており、お客様のサブスクリプション製品に関連するアップストリームコミュニティーに多くの貢献を行えています。プロセスの主な部分である Red Hat セキュリティーアドバイザリーは、脆弱性が最初に公開される同じ日に頻繁に配布されるパッチにより、Red Hat ソリューションに影響を与えるセキュリティー上の欠陥をプロアクティブに通知します。

第2章 脅威および脆弱性管理

Red Hat Ceph Storage(RHCS)は通常、クラウドコンピューティングソリューションと共にデプロイされるため、Red Hat Ceph Storage デプロイメントは、大規模なデプロイメントに含まれる多くのコンポーネントの 1 つとして抽象的に検討することができます。これらのデプロイメントには、通常セキュリティー上の懸念事項があります。これは本ガイドでは セキュリティーゾーン と呼ばれています。脅威アクターとベクトルは、その傾向とリソースへのアクセスに基づいて分類されます。この目的は、ゾーンごとにセキュリティー上の懸念点を明確にすることです。

2.1. 脅威アクター

脅威アクターは、反転する可能性があるアドバーサルのクラスを参照する抽象的な方法です。アクターを使用すると、攻撃の軽減策と防止に必要なセキュリティー制御がより厳格なものになります。セキュリティーは、要件に基づいて利便性、販売、費用のバランスを取る上で役立ちます。場合によっては、Red Hat Ceph Storage デプロイメントを、ここで説明するすべての脅威アクターに対して保護できない場合があります。Red Hat Ceph Storage をデプロイする際には、デプロイメントと使用のバランスを取る場所を決定する必要があります。

リスク評価の一環として、保管するデータタイプとアクセス可能なリソースも考慮する必要があります。これは特定のアクターにも影響します。ただし、データが脅威のアクターになっていない場合でも、コンピューティングリソースに漏えいするだけで済みます。

  • ネーションステートアクター: これは最も有能な敵です。状態のアクターは、ターゲットに対してソフトなリソースを引き起こす可能性があります。これらは、他のどのアクターよりも多くの機能を持ちます。このアクターに対しては、人的および技術の両方の文字列制御がなくても、非常に困難です。
  • 深刻な組織犯罪: このクラスは、非常に有能で経済的に主導された攻撃者のグループを説明します。それらは社内で悪用開発とターゲット調査を行えます。最近は、ロシアの Business Network などの組織が、大規模な自発的な企業でしたが、突然の攻撃がコモディティーになったかを実証しました。エスアポネージは、重大な組織グループ内の範囲内にあります。
  • 非常に有能なグループ: これは、通常は商業的には資金提供されていませんが、サービスプロバイダーやクラウドオペレーターに重大な脅威を招く可能性がる「ハクティビスト」タイプの組織を指します。
  • 一人で行動するやる気のある個人: この攻撃者は、不正または悪意のある従業員、不満を持った顧客、小規模な産業スパイなど、さまざまな形で登場します。
  • 幼稚なクラッカー: この攻撃者は特定の組織をターゲットとしませんが、自動化された脆弱性スキャンと不正使用を実行します。多くの場合、それらは不注意になりますが、このアクターのいずれかによる不正使用は、組織にとって重要なリスクです。

以下のプラクティスは、上記のリスクの一部を軽減するのに役立ちます。

  • セキュリティー更新: ネットワーク、ストレージ、サーバーハードウェアなど、基礎となる物理インフラストラクチャーのエンドツーエンドのセキュリティーポジションを考慮する必要があります。これらのシステムには、独自のセキュリティー強化手段が必要です。Red Hat Ceph Storage デプロイメントでは、セキュリティー更新を定期的にテストし、デプロイする計画が必要です。
  • アクセス管理: アクセス管理には、認証、認可、アカウンティングが含まれます。認証は、ユーザーアイデンティティーを検証するプロセスです。承認は、認証ユーザーにパーミッションを付与するプロセスです。アカウンティングとは、アクションを実行したユーザーを追跡するプロセスのことです。ユーザーにシステムアクセスを付与する場合は、最小権限の原則 を適用し、実際に必要なシステム権限をユーザーにのみ付与します。このアプローチは、システム管理者からの悪意のあるアクターと誤字の両方のリスクを軽減するのに役立ちます。
  • インサイダーの管理: ロールベースのアクセス制御 (最低限必要なアクセス) を慎重に割り当て、内部インターフェースで暗号化を使用し、認証/認可セキュリティー (集中管理など) を使用することで、悪意のあるインサイダーの脅威を軽減できます。役割や不規則なジョブロールローテーションの分離など、技術的ではない他のオプションも検討できます。

2.2. セキュリティーゾーン

セキュリティーゾーンは、共通の信頼要件とシステム内で期待されるユーザー、アプリケーション、サーバー、またはネットワークで構成されます。通常、同じ認証および承認の要件およびユーザーを共有します。これらのゾーンの定義をさらに改良することもできますが、本ガイドでは 4 つの異なるセキュリティーゾーンについて説明しますが、その 3 つはセキュリティーが強化された Red Hat Ceph Storage クラスターのデプロイに必要な最小限の最小値となります。これらのセキュリティーゾーンは、少なくとも以下に信頼されるものから順に一覧表示されます。

  • パブリックセキュリティーゾーン: パブリックセキュリティーゾーンは、クラウドインフラストラクチャーの完全に信頼できない領域です。インターネットを全体として参照することも、単に Red Hat OpenStack デプロイメントの権限を持たないネットワークに対してのみ参照することができます。このゾーンを通過する機密性または整合性要件のあるデータは、暗号化などの補正制御を使用して保護する必要があります。パブリックセキュリティーゾーンは、Ceph Storage クラスターのフロントエンドまたはクライアント側のネットワークと混同 しないようにしてください。これは RHCS の public_network と呼ばれ、パブリックセキュリティーゾーンまたは Ceph クライアントセキュリティーゾーンの一部 ではありません
  • Ceph クライアントセキュリティーゾーン: RHCS では、Ceph クライアントセキュリティーゾーンは、Ceph Object Gateway、Ceph Block Device、Ceph Filesystem、librados などの Ceph クライアントにアクセスするネットワークを指します。通常、Ceph クライアントセキュリティーゾーンはファイアウォールの背後にあります。これは、パブリックセキュリティーゾーンから分離されます。ただし、Ceph クライアントは常にパブリックセキュリティーゾーンから保護される訳ではありません。Ceph Object Gateway の S3 および Swift API をパブリックセキュリティーゾーンで公開することができます。
  • ストレージアクセスセキュリティーゾーン: ストレージアクセスセキュリティーゾーンは、Ceph Storage クラスターにアクセスできる Ceph クライアントを提供する内部ネットワークのことです。本ガイドは OpenStack Platform セキュリティーおよび強化ガイドで使用される用語と一貫性を保つために、フレーズ「ストレージアクセスセキュリティーゾーン」を使用します。ストレージアクセスセキュリティーゾーンには、Ceph Storage クラスターのフロントエンドまたはクライアント側のネットワーク (RHCS の public_network と呼ばれます) が含まれます。
  • Ceph クラスターセキュリティーゾーン: Ceph クラスターセキュリティーゾーンは、レプリケーション、ハートビート、バックフィル、復旧のためのネットワーク通信で Ceph Storage クラスターの OSD デーモンを提供する内部ネットワークを指します。Ceph クラスターセキュリティーゾーンには、Ceph Storage クラスターのバックサイドネットワーク (RHCS の cluster_network と呼ばれます) が含まれます。

これらのセキュリティーゾーンは個別にマッピングすることも、組み合わせて特定の RHCS デプロイメント内の信頼領域の可能性の大半を表します。セキュリティーゾーンは、特定の RHCS デプロイメントトポロジーに対してマッピングする必要があります。ゾーンとその信頼要件は、Red Hat Ceph Storage がスタンドアロンの容量で動作しているか、パブリック、プライベート、またはハイブリッドクラウドを提供するかによって異なります。

これらのセキュリティーゾーンを視覚的に表示するには、「セキュリティー最適化アーキテクチャー」を参照してください。

関連情報

  • 詳細は、『Red Hat Ceph Storage データセキュリティーおよび強化ガイド』「ネットワーク通信」セクションを参照してください。

2.3. 接続セキュリティーゾーン

信頼レベルや認証要件が異なる複数のセキュリティーゾーンにまたがるコンポーネントは、注意して設定する必要があります。これらの接続は多くの場合、ネットワークアーキテクチャーの弱いポイントであり、接続しているゾーンの最も高い信頼レベルのセキュリティー要件を満たすように常に設定する必要があります。多くの場合、接続ゾーンのセキュリティー制御は、攻撃の可能性が高まるため、主な懸念事項となります。ゾーンが満たしているポイントは、攻撃者が攻撃を移行したり、デプロイメントの機密性の高い部分にターゲットさせたりします。

Red Hat Ceph Storage の管理者は、統合ポイントが存在するゾーンよりも高標準の統合ポイントのセキュリティーを保護することを検討してください。たとえば、Ceph Cluster Security Zone は他のセキュリティーゾーンに接続する理由がないため、他のセキュリティーゾーンから簡単に分離できます。一方、Storage Access Security Zone は、Ceph モニターノードのポート 6789 へのアクセスを提供し、Ceph OSD ノード上のポート 6800-7300 を提供する必要があります。ただし、Ceph 管理者にのみ公開される必要がある Ceph Graphana 監視情報へのアクセスを提供するため、ポート 3000 は Storage Access Security Zone のみに限定する必要があります。Ceph クライアントセキュリティーゾーンの Ceph Object Gateway は、Ceph クラスターセキュリティーゾーンのモニター (ポート 6789) および OSD (ポート 6800-7300) にアクセスし、その S3 および Swift API を HTTP ポート 80 や HTTPS ポート 443 経由などのパブリックセキュリティーゾーンに公開する場合がありますが、引き続き管理 API へのアクセスを制限しないといけない場合があります。

Red Hat Ceph Storage の設計では、セキュリティーゾーンの分離が困難です。コアサービスは、通常少なくとも 2 つのゾーンにまたがるため、セキュリティー制御を適用する際に特別な考慮を行う必要があります。

2.4. セキュリティー最適化アーキテクチャー

Red Hat Ceph Storage クラスターのデーモンは通常、サブネットが分離され、ファイアウォールの背後にあるノードで実行されます。これにより、RHCS クラスターのセキュリティーを保護するのは比較的簡単になります。

一方、Ceph ブロックデバイス (rbd)、Ceph ファイルシステム (cephfs)、Ceph オブジェクトゲートウェイ (rgw) などの Red Hat Ceph Storage クライアントは RHCS ストレージクラスターにアクセスしますが、サービスを他のクラウドコンピューティングプラットフォームに公開します。

Ceph セキュリティーガイド 476225 0818

第3章 暗号化および鍵管理

Red Hat Ceph Storage クラスターは通常、プライベートストレージクラスターネットワークを使用している場合など、独自のネットワークセキュリティーゾーンにあります。

重要

攻撃者がパブリックネットワーク上の Ceph クライアントにアクセスできるようにすると、セキュリティーゾーンの分離が不十分な場合があります。

ネットワークトラフィックの機密性または整合性を確保し、Red Hat Ceph Storage が暗号化および鍵管理を使用する場所は、以下のようなセキュリティー上の問題があります。

  • SSH
  • SSL ターミネーション
  • 転送中での暗号化
  • REST での暗号化

3.1. SSH

RHCS クラスターのすべてのノードは、クラスターのデプロイの一部として SSH を使用します。これは、各ノードで以下のようになります。

  • パスワードなしの root 権限で Ansible ユーザーが存在する。
  • SSH サービスが有効になり、拡張ポート 22 が開いている。
  • Ansible ユーザーの公開 SSH 鍵のコピーが利用できる。
重要

エクステンションで Ansible ユーザーにアクセスできるユーザーは、RHCS クラスターの任意のノードで CLI コマンドを root として実行するパーミッションがあります。

詳細は、sudo アクセスを持つ Ansible User の作成」および「Ansible のパスワードなし SSH の有効化」を参照してください。

3.2. SSL ターミネーション

Ceph Object Gateway は HAProxy と併用してデプロイでき、負荷分散とフェイルオーバーのために keepalived を使用することができます。オブジェクトゲートウェイ Red Hat Ceph Storage バージョン 2 および 3 は Civetweb を使用します。以前のバージョンの Civetweb は、SSL 以降のバージョンでは、パフォーマンスが制限された SSL に対応していません。HAProxy と keepalived を使用して SSL 接続を終了する場合は、HAProxy および keepalived コンポーネントは暗号化キーを使用します。

HAProxy と keepalived を使用して SSL を終端する場合、ロードバランサーと Ceph Object Gateway 間の接続は暗号化 されません

詳細は、「Civetweb で SSL を使用」および「HAProxy/keepalived 設定」を参照してください。

3.3. 転送中での暗号化

Red Hat Ceph Storage 4 以降では、スパインバージョン 2 プロトコルの導入により、ネットワーク経由で全 Ceph トラフィックの暗号化を有効にすることができます。メッセンジャー v2 の secure モード設定は、Ceph デーモンと Ceph クライアント間の通信を暗号化し、エンドツーエンドの暗号化を提供します。

メッセンジャー v2 プロトコル

Ceph の有線プロトコルの 2 つ目のバージョンである msgr2 には、以下の新機能が含まれています。

  • ネットワークを通過するすべてのデータを暗号化するセキュアなモード。
  • 認証ペイロードのカプセル化の改善。
  • 機能広告およびネゴシエーションが改善されました。

Ceph デーモンは複数のポートにバインドします。これにより、レガシー、v1 互換のほか、新しい v2 互換の Ceph クライアントが同じストレージクラスターに接続することができます。Ceph Monitor デーモンに接続する Ceph クライアントまたはその他の Ceph デーモンは、まず v2 プロトコルの使用を試みますが、可能でない場合は古い v1 プロトコルが使用されます。デフォルトでは、メッセンジャープロトコル v1v2 の両方が有効です。デフォルトでは、新しい v2 ポートは 3300 で、レガシー v1 ポートは 6789 です。

msgr2 プロトコルは、以下の 2 つの接続モードをサポートします。

  • crc

    • cephx で接続を確立すると、強固な初期認証を提供します。
    • ビットフリップから保護する crc32c 整合性チェックを提供します。
    • 悪意のある中間者攻撃に対する保護は提供しません。
    • Evesdropper が認証後のトラフィックをすべて認識しないようにする訳ではありません。
  • secure

    • cephx で接続を確立すると、強固な初期認証を提供します。
    • 認証後のトラフィックをすべて完全に暗号化します。
    • 暗号化の整合性チェックを提供します。

デフォルトのモードは crc です。

Ceph Object Gateway 暗号化

また、Ceph Object Gateway では、S3 API を使用した顧客提供鍵の暗号化もサポートされます。

重要

転送において厳密な暗号化を必要とする規制コンプライアンス標準に準拠するために、管理者はクライアント側の暗号化で Ceph Object Gateway をデプロイ する必要があります

Ceph ブロックデバイスの暗号化

システム管理者は、Ceph を Red Hat OpenStack Platform 13 暗号化のバックエンドとして統合し、RBD Cinder に dm_crypt を使用して Ceph ブロックデバイスボリュームを Ceph Storage クラスター内で有線暗号化できるようにする 必要があります

重要

転送で厳密な暗号化を必要とする規制コンプライアンス標準に準拠するために、システム管理者は、RBD Cinder に dmcrypt を使用して、Ceph ストレージクラスター内で有線暗号化を行う 必要があります

関連情報

3.3.1. メッセンジャー v2 プロトコルの有効化

Red Hat Ceph Storage 4 の新規インストールでは、msgr2 プロトコルの msgr2 がデフォルトで有効になっています。Red Hat Ceph Storage 3 以前では、Ceph Monitors は古い v1 ポート 6789 にバインドします。アップグレード後に、msgr2 プロトコルを有効にして新機能を利用できます。Ceph Monitor が msgr2 プロトコルにバインドされたら、Ceph Monitor サービスを再起動した後に v2 アドレスのアドバタイズを開始します。msgr2 プロトコルのデフォルト接続モードは crc です。

警告

secure モードを使用すると、ストレージクラスターでパフォーマンスが低下する可能性があります。パフォーマンスの低下の重大度は、複数の環境要因によって異なる場合があります。Red Hat は、実稼働環境で実装する前に、非実稼働環境でのパフォーマンスへの影響をテストすることを推奨します。

重要

現在、CephFS や krbd などの Ceph カーネルクライアントでは、secure モードの使用はサポートされていません。secure モードの使用は、OpenStack Nova、Glance、Cinder などの librbd を使用する Ceph クライアントでサポートされています。

前提条件

  • 稼働中の Red Hat Ceph Storage 4 クラスター。
  • ファイアウォールで TCP ポート 3300 を開きます。
  • Ceph Monitor ノードへのルートレベルのアクセス。

手順

  1. Ceph 設定ファイル (デフォルトでは /etc/ceph/ceph.conf) を開いて編集します。
  2. [global] セクションの下に以下が新しい行に追加されます。

    ms_bind_msgr2 = true
    1. 必要に応じて、Ceph デーモン間の有線暗号化を有効にし、Ceph クライアントとデーモン間の有線暗号化を有効にするには、Ceph 設定ファイルの [global] セクションに以下のオプションを追加します。

      [global]
      ms_cluster_mode=secure
      ms_service_mode=secure
      ms_client_mode=secure
  3. 変更を Ceph 設定ファイルに保存します。
  4. 更新された Ceph 設定ファイルを Red Hat Ceph Storage クラスターのすべてのノードにコピーします。
  5. msgr2 プロトコルを有効にします。

    [root@mon ~]# ceph mon enable-msgr2
  6. 各 Ceph Monitor ノードで Ceph Monitor サービスを再起動します。

    [root@mon ~]# systemctl restart ceph-mon.target

関連情報

3.4. REST での暗号化

Red Hat Ceph Storage は、いくつかのシナリオで使用中の暗号化をサポートします。

  1. Ceph Storage クラスター: Ceph Storage クラスターは、OSD の Linux Unified Key Setup または LUKS 暗号化と、それに対応するジャーナル、ライトアヘッドログ、メタデータデータベースをサポートします。このシナリオでは、クライアントが Ceph Block Device、Ceph Filesystem、Ceph Object Storage クラスター、または librados 上に構築されたカスタムアプリケーションに関係なく、Ceph は残りのデータをすべて暗号化します。
  2. Ceph Object Gateway: Ceph Storage クラスターはクライアントオブジェクトの暗号化をサポートします。Ceph Object Gateway がオブジェクトを暗号化すると、Red Hat Ceph Storage クラスターから独立して暗号化されます。また、送信されるデータは Ceph Object Gateway と Ceph Storage Cluster の間には暗号化された形式です。

Ceph Storage クラスターの暗号化

Ceph Storage クラスターは、OSD に保存されているデータの暗号化をサポートします。Red Hat Ceph Storage は、dmcrypt を指定して lvm で論理ボリュームを暗号化できます。つまり、ceph-volume によって呼び出される lvm は、物理ボリュームではなく OSD の論理ボリュームを暗号化し、同じ OSD キーを使用するパーティション以外の LVM デバイスの暗号化を行う場合があります。論理ボリュームを暗号化することで、より多くの設定の柔軟性が可能になります。

LUKS v1 は、Linux ディストリビューション間で最も幅広いサポートを持つため、Ceph は LUKS v2 ではなく LUKS v1 を使用します。

OSD の作成時に、lvm は秘密鍵を生成し、stdin (標準入力) を介して JSON ペイロードでその鍵を Ceph モニターにセキュアに渡します。暗号化キーの属性名は dmcrypt_key です。

重要

システム管理者は、暗号化を明示的に有効にする必要があります。

デフォルトでは、Ceph は OSD に保存されているデータを暗号化しません。システム管理者は、Ceph Ansible で dmcrypt を有効にする必要があります。group_vars/osds.yml ファイルで dmcrypt オプションを設定する方法は、『Red Hat Ceph Storage インストールガイド』「OSD Ansible 設定」を参照してください。

注記

LUKS および dmcrypt は、保存データの暗号化のみに対応し、移動中のデータの暗号化には対応しません。

Ceph Object Gateway 暗号化

Ceph Object Gateway は、S3 API を使用したお客様提供のキーを使用した暗号化をサポートします。お客様が提供する鍵を使用する場合、S3 クライアントは暗号鍵を各リクエストと共に渡して、暗号化されたデータの読み取りまたは書き込みを行います。これらのキーを管理するのは、お客様の責任です。各オブジェクトの暗号化に使用する Ceph Object Gateway の鍵を覚えておく必要があります。

詳細は、『Red Hat Ceph Storage 開発者ガイド』「S3 API サーバー側暗号化」を参照してください。

第4章 ID およびアクセス管理

Red Hat Ceph Storage は、以下の ID およびアクセス管理を提供します。

  • Ceph Storage クラスターのユーザーアクセス
  • Ceph Object Gateway のユーザーアクセス
  • Ceph Object Gateway LDAP/AD 認証
  • Ceph Object Gateway OpenStack Keystone 認証

4.1. Ceph Storage クラスターのユーザーアクセス

ユーザーを特定し、中間者攻撃から保護するために、Ceph は cephx 認証システムを提供し、ユーザーおよびデーモンを認証します。cephx の詳細情報は、「Ceph ユーザー管理」を参照してください。

重要

cephx プロトコルは、転送時のデータ暗号化または保存時の暗号化には対応 していません

cephx は認証に共有秘密鍵を使用します。つまり、クライアントとモニタークラスターの両方にクライアントの秘密鍵のコピーがあります。認証プロトコルは、両方のユーザーがキーのコピーを持つことを証明できるので、実際に確認する必要はありません。これにより相互認証が提供されます。これは、クラスターが秘密鍵をユーザーが所有していることを確認でき、ユーザーはクラスターに秘密鍵のコピーがあることを確認します。

ユーザーは、Ceph クライアントを使用して Red Hat Ceph Storage クラスターデーモンと対話するアプリケーションなどの個別またはシステムアクターです。

OSD のステータス

Ceph は、デフォルトでは認証および承認で実行されます。Ceph クライアントは、ユーザー名およびキーリングを指定することができます。これには、指定したユーザーの秘密鍵が含まれます。通常、コマンドラインを使用します。ユーザーとキーリングが引数として提供されていない場合、Ceph は client.admin 管理ユーザーをデフォルトとして使用します。キーリングが指定されていない場合は、Ceph が Ceph 設定の keyring 設定を使用してキーリングを探します。

重要

Ceph クラスターを強化するには、キーリングは、現在のユーザーおよび rootのみ 読み取り/書き込み権限を付与します。client.admin 管理ユーザーキーを含むキーリングは root ユーザーに制限する必要があります。

認証を使用するように Red Hat Ceph Storage クラスターを設定する方法は、Red Hat Ceph Storage 4 の『設定ガイド』を参照してください。具体的には、『CephX 設定リファレンス』を参照してください。

4.2. Ceph Object Gateway のユーザーアクセス

Ceph Object Gateway は、ユーザーデータが含まれる S3 および Swift API へのアクセスを認証および認可する独自のユーザー管理で RESTful API サービスを提供します。認証は以下で構成されます。

  • S3 User: S3 API のユーザーのアクセスキーおよびシークレット。
  • Swift ユーザー: Swift API のユーザー向けのアクセスキーおよびシークレットSwift ユーザーは、S3 ユーザーのサブユーザーです。S3 の「parent」ユーザーを削除すると、Swift ユーザーが削除されます。
  • 管理ユーザー: 管理 API のユーザーのアクセスキーおよびシークレット。管理ユーザーは Ceph Admin API にアクセスでき、ユーザーの作成などの機能を実行でき、バケットやコンテナーおよびそのオブジェクトにアクセスする権限を付与できるので、管理ユーザーは慎重に作成する必要があります。

Ceph Object Gateway は、すべてのユーザーの認証情報を Ceph Storage クラスタープールに保存します。名前、メールアドレス、クォータ、用途などのユーザーに関する追加情報を保存することができます。

詳細は、「ユーザー管理」および「管理ユーザーの作成」を参照してください。

4.3. Ceph Object Gateway LDAP/AD 認証

Red Hat Ceph Storage は、Ceph Object Gateway のユーザーを認証する軽量の Directory Access Protocol(LDAP)サーバーをサポートします。LDAP または Active Directory を使用するように設定すると、Ceph Object Gateway のユーザーを認証するために Ceph Object Gateway デバッサーを LDAP サーバーに定義します。

Ceph Object Gateway は LDAP を使用するかどうかを制御します。ただし、設定が完了すると、ユーザーを認証する LDAP サーバーになります。

Ceph Object Gateway と LDAP サーバー間の通信のセキュリティーを保護するために、Red Hat は LDAP セキュアまたは LDAPS を使用して設定をデプロイすることを推奨します。

重要

LDAP を使用する場合は、rgw_ldap_secret = <path-to-secret> シークレットファイルへのアクセスが保護されていることを確認してください。

詳細は、「LDAP/AD を使用する Ceph Object Gateway ガイド」を参照してください。

4.4. Ceph Object Gateway OpenStack Keystone 認証

Red Hat Ceph Storage は、OpenStack Keystone を使用した Ceph Object Gateway Swift API のユーザーを認証することをサポートしています。Ceph Object Gateway では、Keystone トークンを受け入れてユーザーを認証し、対応する Ceph Object Gateway ユーザーを作成することができます。Keystone がトークンを検証すると、Ceph Object Gateway は認証されたユーザーを考慮します。

Ceph Object Gateway は、認証に OpenStack Keystone を使用するかどうかを制御します。ただし、設定が完了すると、ユーザーを認証する OpenStack Keystone サービスになります。

Keystone と連携するように Ceph Object Gateway を設定するには、nss db 形式への要求の作成に Keystone が使用する OpenSSL 証明書を変換する必要があります。

詳細は、「Keystone を使用した Ceph Object Gateway ユーザーの認証」を参照してください。

第5章 インフラストラクチャーのセキュリティー

本ガイドの対象は Red Hat Ceph Storage です。ただし、適切な Red Hat Ceph Storage セキュリティープランには、『Red Hat Enterprise Linux 7 セキュリティーガイド』および『Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理ガイド』を考慮する 必要があります。これは、前述のハイパーリンクによってここに組み込まれます。

警告

Red Hat Ceph Storage のセキュリティー計画は、今後も考慮することなく完了しません。

5.1. 管理

Red Hat Ceph Storage クラスターの管理には、コマンドラインツールの使用が必要です。CLI ツールには、クラスターへの管理者権限に管理者キーが必要です。デフォルトでは、Ceph は管理者キーを /etc/ceph ディレクトリーに保存します。デフォルトのファイル名は ceph.client.admin.keyring です。キーリングのセキュリティーを保護する手順を実行し、クラスターに対する管理権限を持つユーザーのみがキーリングにアクセスできるようにします。

5.2. ネットワーク通信

Red Hat Ceph Storage は以下の 2 つのネットワークを提供します。

  • パブリックネットワーク
  • クラスターネットワーク。

すべての Ceph デーモンおよび Ceph クライアントでは、ストレージアクセスセキュリティーゾーン の一部であるパブリックネットワークへのアクセスが必要です。一方、OSD デーモン のみCeph クラスターセキュリティーゾーン の一部であるクラスターネットワークへのアクセスを必要とします。

ネットワークアーキテクチャー

Ceph の設定には、public_network および cluster_network の設定が含まれます。強化の目的で、CIDR 表記を使用して IP アドレスとネットマスクを指定します。クラスターに複数のサブネットがある場合は、カンマ区切りの IP/netmask エントリーを複数指定します。

public_network = <public-network/netmask>[,<public-network/netmask>]
cluster_network = <cluster-network/netmask>[,<cluster-network/netmask>]

詳細は、『設定ガイド』の「ネットワーク設定リファレンス」を参照してください。

5.3. ネットワークサービスのハードニング

システム管理者は、Red Hat Enterprise Linux 7 サーバーに Red Hat Ceph Storage クラスターをデプロイします。SELinux はデフォルトでオンになっており、ファイアウォールは SSH サービスポート 22 以外の受信トラフィックをすべてブロックします。ただし、その他の承認されていないポートが開いたり不要なサービスが有効にならないようにするため、これが当てはまるようにする 必要 があります。

各サーバーノードで、以下を実行します。

  1. firewalld サービスを起動し、システムの起動時に実行できるようにし、実行していることを確認します。

    # systemctl enable firewalld
    # systemctl start firewalld
    # systemctl status firewalld
  2. 開いているすべてのポートのインベントリーを取得します。

    # firewall-cmd --list-all

    新規インストールでは、sources: セクションを空白にし、ポートが特別に開いていないことを示します。services セクションは、SSH サービス (およびポート 22) および dhcpv6-client が有効になっていることを示します。

    sources:
    services: ssh dhcpv6-client
  3. SELinux が実行され、Enforcing であることを確認します。

    # getenforce
    Enforcing

    SELinux が Permissive の場合は、Enforcing に設定します。

    # setenforce 1

    SELinux が実行されていない場合は、有効にしてください。詳細は『Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理ガイド』を参照してください。

各 Ceph デーモンは、1 つ以上のポートを使用して Red Hat Ceph Storage クラスターの他のデーモンと通信します。場合によっては、デフォルトのポート設定を変更できます。通常、管理者は Ceph Object Gateway または ceph-radosgw デーモンのデフォルトのポートのみを変更します。『オブジェクトゲートウェイの設定および管理ガイド』Changing the CivetWeb portを参照してください。

表5.1 Ceph ポート

ポートデーモン設定オプション

8080

ceph-radosgw

rgw_frontends

6789

ceph-mon

該当なし

6800-7300

ceph-osd

ms_bind_port_min から ms_bind_port_max

6800-7300

ceph-mgr

ms_bind_port_min から ms_bind_port_max

6800

ceph-mds

該当なし

Ceph Storage クラスターのデーモンには、ceph-monceph-mgr、および ceph-osd が含まれます。これらのデーモンとそれらのホストは、Ceph クラスターセキュリティーゾーンで構成されます。これは、ハードニング目的で独自のサブネットを使用する必要があります。

Ceph クライアントには、ceph-radosgwceph-mdsceph-fuselibcephfsrbdlibrbd、および librados が含まれます。これらのデーモンとホストは、ストレージアクセスセキュリティーゾーンで構成されます。これは、強化目的で独自のサブネットを使用する必要があります。

Ceph Storage クラスターゾーンのホストで、Ceph クライアントを実行するホストのみが Ceph Storage Cluster デーモンに接続することを検討します。以下に例を示します。

# firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept"

<zone-name> をゾーン名に置き換えます。<ipaddress> を IP アドレスに置き換え、<netmask> を CIDR 表記のサブネットマスクに置き換えます。<port-number> をポート番号または範囲に置き換えます。--permanent フラグを使用してプロセスを繰り返し、再起動後も変更が維持されるようにします。以下に例を示します。

# firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept" --permanent

特定の手順は、『Red Hat Ceph Storage インストールガイド』の「ファイアウォール」セクションを参照してください。

5.4. 報告

Red Hat Ceph Storage は、基本的なシステム監視を提供し、ceph-mgr デーモンプラグイン (RESTful API、ダッシュボード、その他のプラグイン (Prometheus やZendix など)) と共にレポートします。Ceph は、設定、設定の詳細、および統計情報を取得する collectd およびソケットを使用してこの情報を収集を取得します。

システム管理者は、デフォルトのシステム動作以外に、IP-Tables プラグインまたは ConnTrack プラグインを、オープンポートと接続を追跡するように、セキュリティー上の問題について報告するように collectd を設定することもできます。

システム管理者は、ランタイム時に構成設定を取得することもできます。「Ceph ランタイム設定の表示」を参照してください。

5.5. 管理者アクションの監査

システムセキュリティーの重要な要素として、クラスター上で管理者のアクションを定期的に監査することが挙げられます。Red Hat Ceph Storage は、管理者アクションの履歴を /var/log/ceph/ceph.audit.log ファイルに保存します。

各エントリーには以下が含まれます。

  • タイムスタンプ: コマンドが実行されるタイミングを示します。
  • 監視アドレス: 変更したモニターを識別します。
  • クライアント: 変更を開始するクライアントノードを特定します。
  • エンティティー: 変更を行うユーザーを識別します。
  • コマンド: 実行したコマンドを特定します。

たとえば、システム管理者は nodown フラグを設定および設定解除できます。監査ログでは、以下のようになります。

2018-08-13 21:50:28.723876 mon.reesi003 mon.2 172.21.2.203:6789/0 2404194 : audit [INF] from='client.? 172.21.6.108:0/4077431892' entity='client.admin' cmd=[{"prefix": "osd set", "key": "nodown"}]: dispatch
2018-08-13 21:50:28.727176 mon.reesi001 mon.0 172.21.2.201:6789/0 2097902 : audit [INF] from='client.348389421 -' entity='client.admin' cmd=[{"prefix": "osd set", "key": "nodown"}]: dispatch
2018-08-13 21:50:28.872992 mon.reesi001 mon.0 172.21.2.201:6789/0 2097904 : audit [INF] from='client.348389421 -' entity='client.admin' cmd='[{"prefix": "osd set", "key": "nodown"}]': finished
2018-08-13 21:50:31.197036 mon.mira070 mon.5 172.21.6.108:6789/0 413980 : audit [INF] from='client.? 172.21.6.108:0/675792299' entity='client.admin' cmd=[{"prefix": "osd unset", "key": "nodown"}]: dispatch
2018-08-13 21:50:31.252225 mon.reesi001 mon.0 172.21.2.201:6789/0 2097906 : audit [INF] from='client.347227865 -' entity='client.admin' cmd=[{"prefix": "osd unset", "key": "nodown"}]: dispatch
2018-08-13 21:50:31.887555 mon.reesi001 mon.0 172.21.2.201:6789/0 2097909 : audit [INF] from='client.347227865 -' entity='client.admin' cmd='[{"prefix": "osd unset", "key": "nodown"}]': finished

Ceph などの分散システムでは、1 つのインスタンスでアクションが開始され、クラスター内の他のノードに伝播されます。アクションが開始すると、ログは dispatch を示します。アクションが終了すると、ログは finished したことを示します。

この例では、entity='client.admin' は、ユーザーが admin ユーザーであることを示します。cmd=[{"prefix": "osd set", "key": "nodown"}] コマンドは、管理ユーザーが ceph osd set nodown を実行したことを示しています。

第6章 データの保持

Red Hat Ceph Storage はユーザーデータを保管しますが、通常は間接的な方法で保存されます。カスタマーデータの保持には、Red Hat OpenStack Platform などの他のアプリケーションが必要になる場合があります。

6.1. Ceph Storage クラスター

Ceph Storage クラスター​多くの場合、Reliable Autonomic Distributed Object Store または RADOS と呼ばれます。データをプール内にオブジェクトとして保存します。多くの場合、これらのオブジェクトは Ceph Block Device イメージ、Ceph Object Gateway オブジェクト、Ceph Filesystem ファイルなどのクライアントデータを表すアトミック単位です。ただし、librados 上に構築されたカスタムアプリケーションは、プールにバインドされ、データも保存される可能性があります。

cephx は、オブジェクトデータを格納するプールへのアクセスを制御します。ただし、Ceph Storage Cluster ユーザーは通常 Ceph クライアントで、エンドユーザーではありません。そのため、通常、エンドユーザーは Ceph Storage クラスタープールでオブジェクトを直接書き込み、読み取り、または削除する機能がありません

6.2. Ceph ブロックデバイス

Red Hat Ceph Storage、Ceph ブロックデバイスインターフェース(RADOS Block Device または RBD)の最も一般的な用途は、仮想ボリューム、イメージ、コンピュートインスタンスを作成して、プール内に一連のオブジェクトとして保管します。Ceph は、これらのオブジェクトを配置グループに割り当てるか、クラスター全体で OSD に擬似を分散または配置します。

Ceph ブロックデバイスインターフェースを使用するアプリケーションにより異なります。通常、Red Hat OpenStack Platform ​エンドユーザーは、ボリュームおよびイメージを作成、変更、および削除できます。Ceph は各オブジェクトの CRUD 操作を処理します。

ボリュームとイメージを削除すると、リカバリーできない方法で対応するオブジェクトが破棄されます。ただし、復元的なデータアーティファクトは、上書きされるまでストレージメディアに残り続ける場合があります。データはバックアップアーカイブに残る場合もあります。

6.3. Ceph Filesystem

Ceph Filesystem インターフェースは仮想ファイルシステムを作成し、それらをプール内の一連のオブジェクトとして保存します。Ceph は、これらのオブジェクトを配置グループに割り当てるか、クラスター全体で OSD に擬似を分散または配置します。

通常、Ceph ファイルシステムは 2 つのプールを使用します。

  • メタデータ: メタデータプールは、一般的に inode から構成されるメタデータサーバー (mds) のデータを格納します。つまり、ファイルの所有権、パーミッション、作成日/時刻、最後に修正/アクセスした日時、親ディレクトリーなどです。
  • data: データプールはファイルデータを保存します。Ceph はファイルを 1 つ以上のオブジェクトとして保存する場合があります。通常、エクステントなどのファイルデータのブロックが小さくなる場合があります。

Ceph ファイルシステムインターフェースを使用するアプリケーションにより異なります。通常、Red Hat OpenStack Platform ​エンドユーザーは、Ceph ファイルシステムでファイルを作成、変更、および削除できます。Ceph は、ファイルを表す各オブジェクトの CRUD 操作を処理します。

ファイルを削除すると、リカバリーできない方法で対応するオブジェクトが破棄されます。ただし、復元的なデータアーティファクトは、上書きされるまでストレージメディアに残り続ける場合があります。データはバックアップアーカイブに残る場合もあります。

6.4. Ceph Object Gateway

データのセキュリティーおよび保持の観点からすると、Ceph Object Gateway インターフェースは Ceph Block Device および Ceph Filesystem のインターフェースと比較すると、いくつかの重要な違いがあります。Ceph Object Gateway は、エンドユーザーにサービスを提供します。そのため、Ceph Object Gateway には以下を保存することができます。

  • ユーザー認証情報: ユーザー認証情報は通常、ユーザー ID、ユーザーアクセスキー、およびユーザーシークレットで構成されます。また、ユーザーの名前とメールアドレス(ある場合)で構成される場合もあります。ユーザーがシステムから明示的に削除されていない限り、Ceph Object Gateway はユーザーの認証データを保持します。
  • ユーザーデータ: ユーザーデータは通常、ユーザーまたは管理者が作成したバケットまたはコンテナーと、内部にユーザーが作成した S3 または Swift オブジェクトで構成されます。Ceph Object Gateway インターフェースは、S3 または Swift オブジェクトごとに 1 つ以上の Ceph Storage クラスターオブジェクトを作成し、対応する Ceph Storage クラスターオブジェクトをデータプールに保存します。Ceph Storage クラスターオブジェクトを配置グループに割り当てるか、クラスター全体で OSD に擬似クラスターを分散または配置します。また、Ceph Object Gateway はバケット内またはインデックス内に含まれるオブジェクトのインデックスを保存して、S3 バケットや Swift コンテナーの内容を一覧表示するなどのサービスを有効にすることもできます。また、マルチパートアップロードを実装する場合には、Ceph Object Gateway は S3 または Swift オブジェクトの部分的なアップロードを一時的に保存する場合があります。

    エンドユーザーは、バケットまたはコンテナーの作成、変更、削除、および Ceph Object Gateway に含まれるオブジェクトを作成できます。Ceph は、S3 または Swift オブジェクトを表す各 Ceph Storage クラスターオブジェクトの CRUD 操作を処理します。

    S3 または Swift オブジェクトを削除すると、リカバリー不可能な方法で対応する Ceph Storage クラスターオブジェクトを破棄します。ただし、復元的なデータアーティファクトは、上書きされるまでストレージメディアに残り続ける場合があります。データはバックアップアーカイブに残る場合もあります。

  • ログ: Ceph Object Gateway は、ユーザーが実行しようとしているユーザー操作と実行された操作のログも保存します。このデータは、バケットまたはコンテナーの作成、変更、削除、または S3 または Swift のオブジェクトが S3 バケットまたは Swift コンテナーにあるかに関する追跡性を提供します。ユーザーがデータを削除すると、ロギング情報は影響を受けず、システム管理者によって削除されるか、有効期限ポリシーによって自動的に削除されるまでストレージに残ります。

バケットライフサイクル

Ceph Object Gateway は、オブジェクトの有効期限を含むバケットライフサイクル機能もサポートします。一般データ保護規則などのデータ保持規則では、管理者はオブジェクトの有効期限ポリシーを設定して、その他のコンプライアンス要素のエンドユーザーにアドバタイズする必要があります。

マルチサイト

Ceph Object Gateway は多くの場合、マルチサイトコンテキストでデプロイされます。この場合、ユーザーは複数のサイトにオブジェクトを保存し、Ceph Object Gateway は別の地理的な場所にオブジェクトのレプリカを作成します。たとえば、プライマリークラスターに障害が発生した場合、セカンダリークラスターは操作を再開する可能性があります。別の例として、セカンダリークラスターは、エッジネットワークやコンテンツ駆動ネットワークなど、地理的に異なる場所にある可能性があります。たとえば、クライアントが応答時間、スループット、およびその他のパフォーマンス特性を向上させるために最も近いクラスターにアクセスすることができます。マルチサイトシナリオでは、管理者は各サイトでセキュリティー対策を実施する必要があります。また、複数サイトのシナリオでデータの地理的な分散が発生すると、管理者はデータが突然の境界にまたがるときに規制への影響を認識している必要があります。

第7章 National Information Processing Standard(FIPS)

Red Hat Ceph Storage は、連邦情報処理標準(FIPS)モードで設定された Red Hat Enterprise Linux でサポートされています。FIPS モードは、暗号化ツールがアルゴリズムを適切に実装するようにします。Ceph が FIPS モードで機能するように Ceph の Ceph 設定を変更する必要はありません。FIPS は、オペレーティングシステムで有効にする必要があります。

前提条件

  • FIPS モードが有効になっていると、Red Hat Enterprise Linux 7.6 以降が使用されます。
  • Red Hat Ceph Storage 3.2.z2 以降が使用されます。

手順

  1. Red Hat Enterprise Linux で、システムのインストール時に、またはインストール後に FIPS モードを有効にします。

    1. ベアメタルデプロイメントの場合は、『Red Hat Enterprise Linux 8 セキュリティーおよび強化機能ガイド』ガイドの説明に従ってください。
    2. コンテナーのデプロイメントについては、『Red Hat Enterprise Linux 8 セキュリティーおよび強化機能ガイド』の説明に従ってください。
  2. FIPS モードを確認します。

    [root@mon ~]# fips-mode-setup --check

関連情報

第8章 要約

本ガイドでは、Red Hat Ceph Storage のセキュリティーに関する一般的な概要のみを説明します。その他のヘルプについては、Red Hat Ceph Storage のコンサルティングチームにお問い合わせください。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.