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

Red Hat OpenStack Platform 16.2

グッドプラクティス、コンプライアンス、およびセキュリティーの強化

OpenStack Documentation Team

概要

このガイドでは、Red Hat OpenStack Platform 環境のセキュリティーを強化するためのグッドプラクティスのアドバイスと概念的な情報を提供します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

Jira でドキュメントのフィードバックを提供する

ドキュメントに関するフィードバックを提供するには、Create Issue フォームを使用します。Red Hat OpenStack Platform Jira プロジェクトで Jira Issue が作成され、フィードバックの進行状況を追跡できます。

  1. Jira にログインしていることを確認してください。Jira アカウントをお持ちでない場合は、アカウントを作成してフィードバックを送信してください。
  2. Create Issue をクリックして、Create Issue ページを開きます。
  3. Summary フィールドと Description フィールドに入力します。Description フィールドに、ドキュメントの URL、章またはセクション番号、および問題の詳しい説明を入力します。フォーム内の他のフィールドは変更しないでください。
  4. Create をクリックします。

第1章 セキュリティーの概要

Red Hat Openstack Platform (RHOSP) で提供されるツールを使用して、計画や操作においてセキュリティーの優先順位付けを行い、ユーザーのプライバシーとデータのセキュリティーを強化します。セキュリティー標準の実装に失敗すると、ダウンタイムやデータ違反が発生します。ユースケースは、監査プロセスおよびコンプライアンスプロセスを通過する必要のある法律が適用される場合があります。

注記

本章の手順に従って、お使いの環境のセキュリティーを強化します。ただし、これらの推奨事項はセキュリティーやコンプライアンスを保証しません。環境が独自の要件に基づいてセキュリティーを評価する必要があります。

1.1. Red Hat OpenStack Platform のセキュリティー

デフォルトでは、Red Hat OpenStack Platform (RHOSP) director は、以下のツールを使用してオーバークラウドを作成し、セキュリティーに対するアクセス制御を行います。

SElinux
SELinux は、各プロセスに必要なアクセス制御を提供して、すべてのアクションに明示的なパーミッションを提供することで、RHOSP のセキュリティー拡張機能を提供します。
Podman
コンテナーツールとしての Podman は、root アクセスを持つプロセスが機能する必要のあるクライアント/サーバーモデルを使用しないため、RHOSP のセキュアなオプションです。
システムアクセスの制限
オーバークラウドのデプロイメント時に director が heat-admin に作成する SSH 鍵またはオーバークラウドで作成した SSH キーのいずれかを使用して、オーバークラウドノードにログインすることができます。オーバークラウドノードにログインしてオーバークラウドノードにパスワードで SSH を使用したり、root を使用してオーバークラウドノードにログインしたりすることはできません。

組織のニーズおよび信頼レベルに基づいて、以下に示す新たなセキュリティー機能で director を設定することができます。

  • パブリック TLS および TLS-everywhere
  • OpenStack Key Manager (barbican) とハードウェアセキュリティーモジュールの統合
  • 署名付きイメージおよび暗号化されたボリューム
  • ワークフロー実行を使用したパスワードおよび fernet 鍵のローテーション

1.2. Red Hat OpenStack Platform 管理者ロールを理解する

ユーザーに admin のロールを割り当てると、このユーザーには、任意のプロジェクトの任意のリソースを表示、変更、作成、または削除する権限があります。このユーザーは、公開されている Glance イメージやプロバイダーネットワークなど、プロジェクト間でアクセスできる共有リソースを作成できます。さらに、admin ロールを持つユーザーは、ユーザーを作成または削除し、ロールを管理できます。

ユーザーに admin ロールを割り当てるプロジェクトは、openstack コマンドが実行されるデフォルトのプロジェクトです。たとえば、development という名前のプロジェクトの admin ユーザーが次のコマンドを実行すると、internal-network という名前のネットワークが development プロジェクトに作成されます。

openstack network create internal-network

admin ユーザーは、--project パラメーターを使用して、任意のプロジェクトに internal-network を作成できます。

openstack network create internal-network --project testing

1.3. Red Hat OpenStack Platform におけるセキュリティーゾーンの識別

セキュリティーゾーンは、共通のセキュリティー上の懸念を共有するリソース、アプリケーション、ネットワーク、およびサーバーです。認証認可要件とユーザーを共有するようにセキュリティーゾーンを設計します。クラウドのアーキテクチャー、環境内で許可される信頼レベル、および標準化された要件に基づいて、独自のセキュリティーゾーンを必要な粒度で定義します。ゾーンとその信頼要件は、クラウドインスタンスがパブリック、プライベート、またはハイブリッドであるかによって異なります。

たとえば、Red Hat OpenStack Platform のデフォルトのインストールを以下のゾーンにセグメント化することができます。

表1.1 セキュリティーゾーン

ゾーンNetworks詳細

Public

external

パブリックゾーンは、外部ネットワーク、パブリック API、およびインスタンスの外部接続用のフローティング IP アドレスをホストします。このゾーンは、管理者のコントロール外のネットワークからのアクセスを可能にし、クラウドインフラストラクチャーの信頼されていない領域となります。

Guest

tenant

ゲストゾーンは、プロジェクトのネットワークをホストします。インスタンスへの無制限のアクセスを許可しているパブリッククラウドやプライベートクラウドのプロバイダーには信用されません。

Storage access

storage、storage_mgmt

ストレージアクセスゾーンは、ストレージの管理、監視とクラスタリング、およびストレージのトラフィック用です。

Control

ctlplane、internal_api、ipmi

コントロールゾーンには、アンダークラウド、ホストオペレーティングシステム、サーバーハードウェア、物理ネットワーク、および Red Hat OpenStack Platform director コントロールプレーンも含まれます。

1.4. Red Hat OpenStack Platform におけるセキュリティーゾーンの位置確認

以下のコマンドを実行して、Red Hat OpenStack Platform デプロイメントの物理的な設定に関する情報を収集します。

手順

  1. アンダークラウドにログオンし、stackrc をソースにします。

    $ source /home/stack/stackrc
  2. openstack subnet list を実行して、割り当てられた IP ネットワークと関連するゾーンを照合します。

    openstack subnet list -c Name -c Subnet
    +---------------------+------------------+
    | Name                | Subnet           |
    +---------------------+------------------+
    | ctlplane-subnet     | 192.168.101.0/24 |
    | storage_mgmt_subnet | 172.16.105.0/24  |
    | tenant_subnet       | 172.16.102.0/24  |
    | external_subnet     | 10.94.81.0/24    |
    | internal_api_subnet | 172.16.103.0/24  |
    | storage_subnet      | 172.16.104.0/24  |
    +---------------------+------------------+
  3. openstack server list を実行して、インフラストラクチャーの物理的なサーバーをリストアップします。

    openstack server list -c Name -c Networks
    +-------------------------+-------------------------+
    | Name                    | Networks                |
    +-------------------------+-------------------------+
    | overcloud-controller-0  | ctlplane=192.168.101.15 |
    | overcloud-controller-1  | ctlplane=192.168.101.19 |
    | overcloud-controller-2  | ctlplane=192.168.101.14 |
    | overcloud-novacompute-0 | ctlplane=192.168.101.18 |
    | overcloud-novacompute-2 | ctlplane=192.168.101.17 |
    | overcloud-novacompute-1 | ctlplane=192.168.101.11 |
    +-------------------------+-------------------------+
  4. 物理ノードの設定を問い合わせるには、openstack server list コマンドの ctlplane アドレスを使用します。

    ssh heat-admin@192.168.101.15 ip addr

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

信頼レベルや認証要件が異なる複数のセキュリティーゾーンにまたがるコンポーネントは、慎重に設定する必要があります。これらの接続は、ネットワークアーキテクチャーの弱点になることが多々あります。これらの接続は、接続されるいずれかのゾーンの最高の信頼レベルのセキュリティー要件を満たすように設定されていることを確認してください。多くの場合、攻撃の可能性があるため、接続されたゾーンのセキュリティー制御が主要な懸念事項になります。ゾーンが交わるポイントは、新たな潜在的な攻撃サービスを提供し、攻撃者がデプロイメントのより繊細な部分に攻撃を移行する機会を増やします。

場合によっては、OpenStack 運用者は、統合ポイントのセキュリティーを、それが存在するどのゾーンよりも高い基準で確保することを検討する必要があるかもしれません。上記の API エンドポイントの例では、管理ゾーンが完全に分離されていない場合、敵対者はパブリックゾーンからパブリック API エンドポイントを標的とし、これを足掛かりにして管理ゾーン内の内部または管理者 API を侵害したりアクセスしたりする可能性があります。

OpenStack の設計は、セキュリティーゾーンの分離が難しいようになっています。コアサービスは通常 2 つのゾーンにまたがるので、セキュリティーコントロールを適用する際には、特別な考慮が必要になります。

1.6. 脅威の軽減策

クラウドデプロイメント、パブリック、プライベート、またはハイブリッドの多くのタイプは、一部のセキュリティーの脅威に公開されます。以下のプラクティスを使用すると、セキュリティーの脅威を軽減するのに役立ちます。

  • 最小限の特権の原則を適用します。
  • 内部および外部のインターフェイスに暗号化を使用します。
  • 一元化された ID 管理を使用します。
  • Red Hat OpenStack Platform を常に更新します。

Compute サービスは、悪意のあるアクターに DDoS 攻撃やブルートフォース攻撃のツールを提供できます。防止策としては、出口のセキュリティーグループ、トラフィック検査、侵入検知システム、お客様への教育啓発などがあります。インターネットなどのパブリックネットワークからアクセスできる、またはパブリックネットワークにアクセスできる環境では、理想的にアウトバウンドの不正使用を検出し、またそれに対処するためのプロセスとインフラストラクチャーを整備する必要があります。

第2章 RHOSP 環境のドキュメント化

システムのコンポーネント、ネットワーク、サービス、およびソフトウェアを文書化することは、セキュリティー上の懸念事項、攻撃ベクトル、およびセキュリティーゾーンの橋渡しとなりうるポイントを特定する上で重要です。Red Hat OpenStack Platform (RHOSP) デプロイメントに関する文書には、以下の情報が含まれている必要があります。

  • RHOSP の本番環境、開発環境、テスト環境におけるシステムコンポーネント、ネットワーク、サービス、ソフトウェアの説明。
  • 仮想マシンや仮想ディスクボリュームなどの一時リソースのインベントリー。

2.1. システムロールの文書化

Red Hat OpenStack Platform (RHOSP) デプロイメントの各ノードは、クラウドのインフラストラクチャーに貢献したり、クラウドのリソースを提供したりと、特定ロールを果たしています。

インフラストラクチャーに貢献するノードは、メッセージキューイングサービス、ストレージ管理、モニタリング、ネットワークなど、クラウドの運用やプロビジョニングをサポートするために必要なクラウド関連サービスを実行します。インフラストラクチャーロールの例としては、以下のようなものがあります。

  • Controller
  • Networker
  • Database
  • Telemetry

クラウドリソースを提供するノードは、お客様のクラウド上で動作するインスタンスのために、コンピュートやストレージの容量を提供します。リソースロールの例としては、以下のようなものがあります。

  • CephStorage
  • Compute
  • ComputeOvsDpdk
  • ObjectStorage

お客様の環境で使用されているシステムロールを文書化します。これらのロールは、RHOSP のデプロイに使用されるテンプレート内で識別できます。たとえば、お客様の環境で使用されている各ロールの NIC 設定ファイルがあります。

手順

  1. デプロイメント用の既存のテンプレートに、現在使用されているロールを指定するファイルがあるかどうかを確認します。お客様の環境で使用されている各ロールの NIC 設定ファイルがあります。次の例では、RHOSP 環境に ComputeHCI ロール、Compute ロール、および Controller ロールが含まれています。

    $ cd ~/templates
    $ tree
    .
    ├── environments
    │   └── network-environment.yaml
    ├── hci.yaml
    ├── network
    │   └── config
    │       └── multiple-nics
    │           ├── computehci.yaml
    │           ├── compute.yaml
    │           └── controller.yaml
    ├── network_data.yaml
    ├── plan-environment.yaml
    └── roles_data_hci.yaml
  2. RHOSP 環境の各ロールは、相互に関連する多くのサービスを実行します。各ロールが使用するサービスを記録するには、roles ファイルを調べる必要があります。

    1. テンプレート用に roles ファイルが生成されている場合は、~/templates ディレクトリーにあります。

      $ cd ~/templates
      $ find . -name *role*
      > ./templates/roles_data_hci.yaml
    2. お使いのテンプレートに roles ファイルが生成されていない場合は、現在使用しているロールに生成し、ドキュメント作成のために検査することができます。

      $ openstack overcloud roles generate \
      > --roles-path /usr/share/openstack-tripleo-heat-templates/roles \
      > -o roles_data.yaml Controller Compute

2.2. ハードウェアインベントリーの作成

イントロスペクションで収集されたデータを表示することで、Red Hat OpenStack Platform のデプロイメントに関するハードウェア情報を取得できます。Introspection では、CPU、メモリー、ディスクなどのハードウェア情報をノードから収集します。

手順

  1. アンダークラウドから、stackrc ファイルのソースを作成します。

    $ source ~/stackrc
  2. 環境内のノードをリスト表示します。

    $ openstack baremetal node list -c Name
    +--------------+
    | Name         |
    +--------------+
    | controller-0 |
    | controller-1 |
    | controller-2 |
    | compute-0    |
    | compute-1    |
    | compute-2    |
    +--------------+
  3. 情報を収集する各ベアメタルノードについて、以下のコマンドを実行してイントロスペクションデータを取得します。

    $ openstack baremetal introspection data save <node> | jq

    <node> を手順 1 で取得したリストのノードの名前に置き換えます。

  4. オプション: 特定の種類のハードウェアに出力を限定するには、インベントリーキーのリストを取得し、特定のキーのイントロスペクションデータを表示することができます。

    1. イントロスペクションデータからトップレベルのキーのリストを得るために、次のコマンドを実行します。

      $ openstack baremetal introspection data save controller-0 | jq '.inventory | keys'
      
      [
        "bmc_address",
        "bmc_v6address",
        "boot",
        "cpu",
        "disks",
        "hostname",
        "interfaces",
        "memory",
        "system_vendor"
      ]
    2. disks などのキーを選択し、次のように実行すると、詳細な情報が得られます。

      $ openstack baremetal introspection data save controller-1 | jq '.inventory.disks'
      [
        {
          "name": "/dev/sda",
          "model": "QEMU HARDDISK",
          "size": 85899345920,
          "rotational": true,
          "wwn": null,
          "serial": "QM00001",
          "vendor": "ATA",
          "wwn_with_extension": null,
          "wwn_vendor_extension": null,
          "hctl": "0:0:0:0",
          "by_path": "/dev/disk/by-path/pci-0000:00:01.1-ata-1"
        }
      ]

2.3. ソフトウェアインベントリーの作成

Red Hat OpenStack Platform (RHOSP) インフラストラクチャーにデプロイしたノードで使用されているソフトウェアコンポーネントを文書化します。システムデータベース、RHOSP ソフトウェアサービス、およびロードバランサー、DNS、または DHCP サービスなどのサポートコンポーネントは、ライブラリー、アプリケーション、またはソフトウェアのクラスにおける漏洩や脆弱性の影響を評価する際に重要です。

手順

  1. 悪意ある活動の対象となりうるシステムやサービスのエントリーポイントを確実に把握します。アンダークラウド上で以下のコマンドを実行します。

    $ cat /etc/hosts
    $ source stackrc ; openstack endpoint list
    $ source overcloudrc ; openstack endpoint list
  2. RHOSP はコンテナー化されたサービスにデプロイされているため、オーバークラウドノード上で稼働しているコンテナーを確認することで、そのノード上のソフトウェアコンポーネントを確認することができます。ssh を使用してオーバークラウドノードに接続し、実行中のコンテナーをリスト表示します。たとえば、compute-0 のオーバークラウドサービスを表示するには、以下のようなコマンドを実行します。

    $ ssh heat-admin@compute-0 podman ps

第3章 TLS と PKI を使用して Red Hat OpenStack デプロイメントを保護する

Red Hat OpenStack Platform は、保護可能な機密データを処理する多くのネットワークとエンドポイントで設定されています。Transport Layer Security (TLS) を使用する場合は、対称キー暗号化でトラフィックを保護します。キーと暗号は TLS ハンドシェイクでネゴシエートされます。これには、認証局 (CA) と呼ばれる仲介者の共有信頼によるサーバーの ID の検証が必要です。

Public Key Infrastructure (PKI) は、認証局を通じてエンティティーを検証するためのフレームワークです。

3.1. 公開鍵基盤 (PKI) のコンポーネント

PKI のコアコンポーネントを次の表に示します。

表3.1 主要な用語

用語定義

エンドエンティティー

デジタル証明書を使用して自身を検証するユーザー、プロセス、またはシステム。

認証局 (CA)

CA は、エンドエンティティーと、エンドエンティティーを検証する依拠当事者の両方によって信頼されるエンティティーです。

依拠当事者

依拠当事者は、エンドエンティティーの検証としてデジタル証明書を受け取り、デジタル証明書を検証する機能を備えています。

デジタル証明書

署名付き公開鍵証明書には、検証可能なエンティティーと公開鍵があり、CA によって発行されます。CA が証明書に署名すると、秘密鍵で暗号化された証明書からメッセージダイジェストが作成されます。CA に関連付けられた公開鍵を使用して、署名を検証できます。X.509 標準は、証明書の定義に使用されます。

Registration Authority (RA)

RA は、CA によって証明書が発行される前に、エンドエンティティーの認証などの管理機能を実行できるオプションの専用機関です。RA がない場合、CA はエンドエンティティーを認証します。

証明書失効リスト (CRL)

CRL は、失効した証明書のシリアル番号のリストです。シリアル番号が取り消された証明書を提示するエンドエンティティーは、PKI モデルでは信頼されません。

CRL 発行者

CA が証明書失効リストの公開を委譲するオプションのシステム。

証明書リポジトリー

エンドエンティティー証明書と証明書失効リストが格納され、クエリーが実行される場所。

3.2. 認証局の要件と推奨事項

公開されている Red Hat OpenStack Platform ダッシュボードまたは公開されている API については、広く認知されている認証局 (CA) によって署名された証明書を取得する必要があります。

TLS で保護する各エンドポイントに DNS ドメインまたはサブドメインを付与する必要があります。指定したドメインは、CA が発行する証明書を作成するために使用されます。CA がエンドポイントを検証できるように、顧客は DNS 名を使用してダッシュボードまたは API にアクセスします。

Red Hat は、内部トラフィックを保護するために、別の内部管理 CA を使用することを推奨します。これにより、クラウドデプロイヤーは秘密鍵インフラストラクチャー (PKI) 実装の制御を維持でき、内部システムの証明書の要求、署名、デプロイが容易になります。

オーバークラウドのエンドポイントで SSL/TLS を有効にすることができます。どこでも TLS (TLS-e) を設定するために必要な証明書の数が多いため、director は Red Hat Identity Management (IdM) サーバーと統合して認証局として機能し、オーバークラウド証明書を管理します。TLS-e の設定の詳細については、Ansible を使用した TLS-e の実装 を参照してください。

OpenStack 全コンポーネントの TLS サポートのステータスを確認するには、TLS Enablement status matrix を参照してください。

独自の認証局で SSL 証明書を使用する場合は、オーバークラウドのパブリックエンドポイントでの SSL/TLS の有効化 を参照してください。

注記

これにより、パブリックにアクセス可能なエンドポイントのみで SSL/TLS を使用する Red Hat OpenStack Platform が設定されます。

3.3. 環境内の TLS バージョンの識別

重要

TLS バージョン 1.0 は、Red Hat OpenStack Platform では非推奨です。さらに、NIST 承認には少なくとも TLS 1.2 を使用する必要があります。詳細は、Transport Layer Security (TLS) 実装の選択、設定、および使用に関するガイドライン を参照してください。

cipherscan を使用して、デプロイで提示されている TLS のバージョンを確認できます。暗号スキャンは、https://github.com/mozilla/cipherscan からクローンできます。この出力例は、horizon から受信した結果を示しています。

注記

実稼働以外のシステムから cipherscan を実行すると、初回実行時に追加の依存関係をインストールする場合があるためです。

$ ./cipherscan https://openstack.lab.local
..............................
Target: openstack.lab.local:443

prio  ciphersuite                  protocols  pfs                 curves
1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2    ECDH,P-256,256bits  prime256v1
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2    ECDH,P-256,256bits  prime256v1
3     DHE-RSA-AES128-GCM-SHA256    TLSv1.2    DH,1024bits         None
4     DHE-RSA-AES256-GCM-SHA384    TLSv1.2    DH,1024bits         None
5     ECDHE-RSA-AES128-SHA256      TLSv1.2    ECDH,P-256,256bits  prime256v1
6     ECDHE-RSA-AES256-SHA384      TLSv1.2    ECDH,P-256,256bits  prime256v1
7     ECDHE-RSA-AES128-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
8     ECDHE-RSA-AES256-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
9     DHE-RSA-AES128-SHA256        TLSv1.2    DH,1024bits         None
10    DHE-RSA-AES128-SHA           TLSv1.2    DH,1024bits         None
11    DHE-RSA-AES256-SHA256        TLSv1.2    DH,1024bits         None
12    DHE-RSA-AES256-SHA           TLSv1.2    DH,1024bits         None
13    ECDHE-RSA-DES-CBC3-SHA       TLSv1.2    ECDH,P-256,256bits  prime256v1
14    EDH-RSA-DES-CBC3-SHA         TLSv1.2    DH,1024bits         None
15    AES128-GCM-SHA256            TLSv1.2    None                None
16    AES256-GCM-SHA384            TLSv1.2    None                None
17    AES128-SHA256                TLSv1.2    None                None
18    AES256-SHA256                TLSv1.2    None                None
19    AES128-SHA                   TLSv1.2    None                None
20    AES256-SHA                   TLSv1.2    None                None
21    DES-CBC3-SHA                 TLSv1.2    None                None

Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature
TLS ticket lifetime hint: None
NPN protocols: None
OCSP stapling: not supported
Cipher ordering: server
Curves ordering: server - fallback: no
Server supports secure renegotiation
Server supported compression methods: NONE
TLS Tolerance: yes

Intolerance to:
 SSL 3.254           : absent
 TLS 1.0             : PRESENT
 TLS 1.1             : PRESENT
 TLS 1.2             : absent
 TLS 1.3             : absent
 TLS 1.4             : absent

サーバーのスキャン時に、Cipherscan インターバリーが、ネゴシエートする最大の TLS バージョンである特定の TLS バージョンのサポートをアドバータイズします。ターゲットサーバーが TLS プロトコルを正しく従うと、相互に対応している最新バージョンで応答します。これは、最初にアドバータイズされた Cipherscan よりも低くなる可能性があります。サーバーが特定のバージョンを使用するクライアントとの接続を確立し続けると、そのプロトコルバージョンに対する耐性があるとみなされません。(指定されたバージョンまたは下位バージョンを使用する) 接続を確立しない場合は、そのバージョンのプロトコルの耐性があることが考慮されます。以下に例を示します。

Intolerance to:
 SSL 3.254           : absent
 TLS 1.0             : PRESENT
 TLS 1.1             : PRESENT
 TLS 1.2             : absent
 TLS 1.3             : absent
 TLS 1.4             : absent

この出力では、TLS 1.0 および TLS 1.1 のイントレランスは PRESENT として報告されます。これは、接続を確立できず、その Cipherscan がこれらの TLS バージョンのアドバタイズメントサポート中に接続できなかったことを意味します。そのため、スキャンされたサーバーでプロトコルの (およびそれより低い) バージョンが有効ではないことを確認する必要があります。

3.4. OpenStack 向けの Identity Management (IdM) サーバーの推奨事項

Red Hat では IdM サーバーと OpenStack 環境の統合が円滑に進むように、以下の情報を提供しています。

IdM インストール用に Red Hat Enterprise Linux を準備する方法は、Identity Management のインストール を参照してください。

ipa-server-installコマンドを実行して、IdM をインストールおよび設定します。コマンドパラメーターを使用すると対話型プロンプトをスキップできます。IdM サーバーを Red Hat Open Stack Platform 環境と統合できるように、以下の推奨事項を使用してください。

表3.2 パラメーターの推奨事項

オプション推奨事項

--admin-password

指定した値をメモしておいてください。Red Hat Open Stack Platform を IdM と連携するように設定するときに、このパスワードが必要になります。

--ip-address

指定した値をメモしておいてください。アンダークラウドノードとオーバークラウドノードには、この IP アドレスへのネットワークアクセスが必要です。

--setup-dns

このオプションを使用して、IdM サーバーに統合 DNS サービスをインストールします。アンダークラウドノードとオーバークラウドノードは、ドメイン名の解決に IdM サーバーを使用します。

--auto-forwarders

このオプションを使用して、 /etc/resolv.confのアドレスを DNS フォワーダーとして使用します。

--auto-reverse

このオプションを使用して、IdM サーバーの IP アドレスのリバースレコードとゾーンを解決します。リバースレコードもゾーンも解決できない場合には、IdM はリバースゾーンを作成します。こうすることで IdM のデプロイメントが簡素化されます。

--ntp-server, --ntp-pool

これらのオプションの両方またはいずれかを使用して、NTP ソースを設定できます。Id M サーバーと Open Stack 環境の両方で、時間が正しく同期されている必要があります。

Red Hat Open Stack Platform ノードとの通信を有効にするには、IdM に必要なファイアウォールポートを開く必要があります。詳細は、IdM に必要なポートの解放 を参照してください。

3.5. Ansible を使用した TLS-e の実装

新しい tripleo-ipa メソッドを使用して、どこでも TLS (TLS-e) と呼ばれるオーバークラウドエンドポイントで SSL/TLS を有効にすることができます。必要な証明書の数が多いため、Red Hat OpenStack Platform は Red Hat Identity Management (IdM) と統合されています。tripleo-ipa を使用して TLS-e を設定する場合、IdM が認証局です。

前提条件

stack ユーザーの作成など、アンダークラウドの設定手順がすべて完了していること。詳細は、Director Installation and Usage を参照してください。

手順

次の手順で、Red Hat OpenStack Platform の新規インストール、または TLS-e で設定する既存のデプロイメントに TLS-e を実装します。事前にプロビジョニングされたノードに TLS-e を設定した Red Hat OpenStack Platform をデプロイする場合は、この方式を使用する必要があります。

注記

既存の環境に TLS-e を実装している場合は、openstack undercloud installopenstack overcloud deploy などのコマンドを実行する必要があります。これらの手順はべき等性を持ち、更新されたテンプレートおよび設定ファイルと一致するように既存のデプロイメント設定を調整するだけです。

  1. /etc/resolv.conf ファイルを設定します。

    アンダークラウドの /etc/resolv.conf に、適切な検索ドメインおよびネームサーバーを設定します。たとえば、デプロイメントドメインが example.com で FreeIPA サーバーのドメインが bigcorp.com の場合、以下の行を /etc/resolv.conf に追加します。

    search example.com bigcorp.com
    nameserver $IDM_SERVER_IP_ADDR
  2. 必要なソフトウェアをインストールします。

    sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
  3. ご自分の環境に固有の値で環境変数をエクスポートします。

    export IPA_DOMAIN=bigcorp.com
    export IPA_REALM=BIGCORP.COM
    export IPA_ADMIN_USER=$IPA_USER 1
    export IPA_ADMIN_PASSWORD=$IPA_PASSWORD 2
    export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
    export UNDERCLOUD_FQDN=undercloud.example.com 3
    export USER=stack
    export CLOUD_DOMAIN=example.com
    1 2
    IdM のユーザー認証情報は、新しいホストおよびサービスを追加できる管理ユーザーでなければなりません。
    3
    UNDERCLOUD_FQDN パラメーターの値は、/etc/hosts の最初のホスト名から IP へのマッピングと一致します。
  4. アンダークラウドで undercloud-ipa-install.yaml Ansible Playbook を実行します。

    ansible-playbook \
    --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
    /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml
  5. undercloud.conf に以下のパラメーターを追加します。

    undercloud_nameservers = $IDM_SERVER_IP_ADDR
    overcloud_domain_name = example.com
  6. [オプション] IPA レルムが IPA ドメインと一致しない場合は、certmonger_krb_realm パラメーターの値を設定します。

    1. /home/stack/hiera_override.yamlcertmonger_krb_realm の値を設定します。

      parameter_defaults:
        certmonger_krb_realm = EXAMPLE.COMPANY.COM
    2. undercloud.confcustom_env_files パラメーターの値を /home/stack/hiera_override.yaml に設定します。

      custom_env_files = /home/stack/hiera_override.yaml
  7. アンダークラウドをデプロイします。

    openstack undercloud install

検証

以下の手順を実施して、アンダークラウドが正しく登録されたことを確認します。

  1. IdM のホストをリスト表示します。

    $ kinit admin
    $ ipa host-find
  2. アンダークラウドに /etc/novajoin/krb5.keytab が存在することを確認します。

    ls /etc/novajoin/krb5.keytab
注記

novajoin というディレクトリー名は、従来の方式に対応させる目的でのみ使用されています。

オーバークラウドでの TLS-e の設定

TLS everywhere (TLS-e) を設定したオーバークラウドをデプロイする場合、アンダークラウドおよびオーバークラウドの IP アドレスは自動的に IdM に登録されます。

  1. オーバークラウドをデプロイする前に、以下のような内容で YAML ファイル tls-parameters.yaml を作成します。お使いの環境に固有の値を選択してください。

    parameter_defaults:
        DnsSearchDomains: ["example.com"]
        DnsServers: ["192.168.1.13"]
        CloudDomain: example.com
        CloudName: overcloud.example.com
        CloudNameInternal: overcloud.internalapi.example.com
        CloudNameStorage: overcloud.storage.example.com
        CloudNameStorageManagement: overcloud.storagemgmt.example.com
        CloudNameCtlplane: overcloud.ctlplane.example.com
        IdMServer: freeipa-0.redhat.local
        IdMDomain: redhat.local
        IdMInstallClientPackages: False
    
    resource_registry:
          OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml
    • OS::TripleO::Services::IpaClient パラメーターに示す値は、enable-internal-tls.yaml ファイルのデフォルト設定を上書きします。openstack overcloud deploy コマンドで、enable-internal-tls.yaml の後に tls-parameters.yaml ファイルを指定するようにします。
    • TLS-e の実装に使用するパラメーターの詳細は、tripleo-ipa のパラメーター を参照してください。
  2. [オプション] IPA レルムが IPA ドメインと一致しない場合は、tls-parameters.yaml ファイルに CertmongerKerberosRealm パラメーターの値も含める必要があります。

        CertmongerKerberosRealm: EXAMPLE.COMPANY.COM
  3. オーバークラウドをデプロイする。デプロイメントコマンドに tls-parameters.yaml を追加する必要があります。

    DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
    CUSTOM_TEMPLATES=/home/stack/templates
    
    openstack overcloud deploy \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
    -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
    ...
  4. keystone にエンドポイントリストのクエリーを行い、各エンドポイントが HTTPS を使用していることを確認します。

    openstack endpoint list

3.6. tripo-ipa のパラメーター

クラウドの完全修飾ドメイン名 (FQDN) を使用して、tripleo-ipa に必要なクラウド名とクラウドドメインパラメーターを定義します。たとえば、FQDN が overcloud.example.com の場合は、次の値を使用します。

  • CloudDomain: example.com
  • CloudName: overcloud.example.com
  • CloudNameCtlplane: overcloud.ctlplane.example.com
  • CloudNameInternal: overcloud.internalapi.example.com
  • CloudNameStorage: overcloud.storage.example.com
  • CloudNameStorageManagement: overcloud.storagemgmt.example.com

環境の要件に基づいて、次の追加パラメーターを設定します。

CertmongerKerberosRealm
CertmongerKerberosRealm パラメーターを IPA レルムの値に設定します。これは、IPA レルムが IPA ドメインと一致しない場合に必要です。
DnsSearchDomains
DnsSearchDomains パラメーターは、コンマ区切りのリストです。IdM サーバーのドメインがクラウドドメインと異なる場合は、DnsSearchDomains パラメーターに IdM サーバーのドメインを含めます。
DnsServers
DnsServers パラメーターを、IdM サーバーの IP アドレスを反映する値に設定します。
EnableEtcdInternalTLS
TLS を分散コンピュートノード (DCN) アーキテクチャーにデプロイする場合は、値 True を指定して EnableEtcdInternalTLS パラメーターを追加する必要があります。
IDMInstallClientPackages
コンピュートノードを事前にプロビジョニングした場合は、IDMInstallClientPackages パラメーターの値を True に設定します。それ以外の場合は、値をFalseに設定します。
IDMModifyDNS
IDMModifyDNS パラメーターを false に設定して、Red Hat Identity Server 上のオーバークラウドノードの自動 IP 登録を無効にします。
IdmDomain
IdmDomain パラメーターを Red Hat Identity サーバーの FQDN のドメイン部分に設定します。指定した値は、IdM レルムの値としても使用されます。IdM ドメインと IdM レルムが異なる場合は、CertmongerKerberosRealm パラメーターを使用してレルムを明示的に設定します。
IdmServer
IdmServer パラメーターを Red Hat Identity サーバーの FQDN に設定します。複製された IdM 環境を使用する場合は、コンマ区切りのリストを使用して複数の値を設定します。IdM レプリカの詳細については、IdM レプリカのインストール を参照してください。

3.7. TLS everywhere (TLS-e) による memcached トラフィックの暗号化

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能の詳細は、対象範囲の詳細 を参照してください。

memcached トラフィックを TLS-e で暗号化できるようになりました。この機能は、novajoin と tripleo-ipa の両方で機能します。

  1. 以下の内容で memcached.yaml という名前の環境ファイルを作成し、memcached の TLS サポートを追加します。

    parameter_defaults:
        MemcachedTLS: true
        MemcachedPort: 11212
  2. オーバークラウドのデプロイプロセスに memcached.yaml 環境ファイルを追加します。

    openstack overcloud deploy --templates \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
    -e /home/stack/memcached.yaml
    ...

関連情報

3.8. 秘密鍵のサイズの拡大

暗号化されたサービストラフィックの証明書の作成に使用される秘密鍵のサイズを大きくすることで、セキュリティーを向上させることができます。デフォルトの RHOSP 秘密鍵のサイズである 2048 ビットは、米国国立標準技術研究所 (NIST) が推奨する最小値と同じです。

  • 秘密鍵のサイズをグローバルに変更するには、CertificateKeySize パラメーターを使用します。
  • RedisCertificateKeySize などのサービス固有のパラメーターを使用して、特定の秘密鍵を変更したり、グローバルの CertificateKeySize パラメーターをオーバーライドしたりします。

環境 Heat テンプレートでこれらのパラメーターを使用し、そのテンプレートをオーバークラウドのデプロイメントコマンドに含めます。オーバークラウドをすでにデプロイしている場合は、最初に使用したものと同じテンプレートを使用して同じ openstack overcloud deploy コマンドを再実行して、新しいパラメーターを追加し、変更を有効にする必要があります。

次の例では、秘密鍵のグローバル値は 4096 です。RedisCertificateKeySize がグローバルパラメーターをオーバーライドするため、redis の秘密鍵は 2048 になります。

parameter_defaults:
    CertificateKeySize: '4096'
    RedisCertificateKeySize: '2048'

第4章 アイデンティティーおよびアクセス管理

Identity サービス (keystone) は、Red Hat OpenStack Platform 環境でクラウドユーザーの認証と認可を提供します。エンドユーザーの直接認証に Identity サービスを使用するか、セキュリティー要件を満たすため、または現在の認証インフラストラクチャーに一致するように外部認証方法を使用するように設定できます。

4.1. Red Hat OpenStack Platform fernet トークン

認証後、Identity サービス (keystone) は次のことを行います。

  • fernet トークンと呼ばれる暗号化されたベアラートークンを発行します。このトークンは ID を表します。
  • ロールに基づいて操作を実行する権限を付与します。

デフォルトでは、各 fernet トークンは最大 1 時間有効です。これにより、ユーザーは再認証を必要とせずに一連のタスクを実行できます。

Fernet は、UUID トークンプロバイダーに代わるデフォルトのトークンプロバイダーです。

4.2. OpenStack Identity サービスエンティティー

Red Hat OpenStack Identity サービス (keystone) は、以下のエンティティーを認識します。

ユーザー
OpenStack Identity サービス (keystone) ユーザーは、認証の最小単位です。ユーザーを認証するには、プロジェクトでロールを割り当てる必要があります。
グループ
OpenStack Identity サービスグループは、ユーザーの論理グループです。グループでは、特定のロールのプロジェクトにアクセスできるようにします。ユーザーではなくグループを管理すると、ロールの管理が簡素化されます。
ロール
OpenStack Identity サービスロールは、それらのロールが割り当てられたユーザーまたはグループがアクセスできる OpenStack API を定義します。
プロジェクト
OpenStack Identity サービスプロジェクトは、ユーザーの分離グループで、物理リソースの共有クォータとそれらの物理リソースから構築された仮想インフラストラクチャーに対する共通のアクセス権が割り当てられます。
ドメイン
OpenStack Identity サービスドメインは、プロジェクト、ユーザー、およびグループの高レベルのセキュリティー境界です。OpenStack Identity ドメインを使用して、keystone ベースのすべての ID コンポーネントを集中管理できます。Red Hat OpenStack Platform は、複数のドメインをサポートしています。別々の認証バックエンドを使用して、異なるドメインのユーザーを表すことができます。

4.3. キーストーンによる認証

OpenStack Identity サービス (keystone) に必要な認証セキュリティー要件を調整できます。

表4.1 ID サービスの認証パラメーター

パラメーター

説明

KeystoneChangePasswordUponFirstUse

このオプションを有効にすると、ユーザーの作成時や、管理者がパスワードをリセットした場合に、ユーザーによるパスワードの変更が必要となります。

KeystoneDisableUserAccountDaysInactive

ユーザーが認証なしでアカウントを使用し続けることのできる最大日数。この期間が過ぎるとアカウントは非アクティブと見なされて自動的に無効 (ロック状態) になります。

KeystoneLockoutDuration

認証の最大試行回数 (KeystoneLockoutFailureAttempts で指定) を超過した場合にユーザーアカウントがロックされる秒数

KeystoneLockoutFailureAttempts

ユーザーの認証失敗がこの最大回数を超えると、KeystoneLockoutDuration で指定された秒数の期間ユーザーアカウントがロックされます。

KeystoneMinimumPasswordAge

ユーザーがパスワードを変更できるようになるまで、そのパスワードを使用する必要のある日数。これは、パスワードの履歴を消去して古いパスワードを再利用するためにユーザーがパスワードを直ちに変更するのを防ぎます。

KeystonePasswordExpiresDays

ユーザーにパスワードの変更を要求する前に、パスワードが有効と見なされる日数。

KeystoneUniqueLastPasswordCount

これにより、新たに作成されたパスワードが一意であることを強制するために、履歴に保管する以前のユーザーパスワードのイテレーション数が制御されます。

4.4. Identity サービスの heat パラメーターを使用した無効なログイン試行阻止

ログイン試行の失敗が繰り返される場合は、ブルートフォース攻撃が試みられている可能性があります。ログインに何度も失敗した場合、Identity Service を使用してアカウントへのアクセスを制限できます。

前提条件

  • Red Hat OpenStack Platform director 環境がインストールされている。
  • スタックとしてディレクターにログインしています。

手順

  1. ユーザーアカウントがロックされる前にユーザーが認証に失敗できる最大回数を設定するには、環境ファイルで KeystoneLockoutFailureAttempts および KeystoneLockoutDuration heat パラメーターの値を設定します。次の例では、KeystoneLockoutDuration が 1 時間に設定されています。

    parameter_defaults
        KeystoneLockoutDuration: 3600
        KeystoneLockoutFailureAttempts: 3
  2. 環境ファイルをデプロイスクリプトに追加します。以前にデプロイされた環境でデプロイスクリプトを実行すると、追加のパラメーターで更新されます。

    openstack overcloud deploy --templates \
    ...
    -e keystone_config.yaml
    ...

4.5. 外部 ID プロバイダーによる認証

外部認証プロバイダー (IdP) を使用して OpenStack サービスプロバイダー (SP) に対して認証することができます。SP は、OpenStack クラウドによって提供されるサービスです。

別の IdP を使用する場合、外部認証のクレデンシャルは、他の OpenStack サービスによって使用されるデータベースからは分離されます。このように分離することで、保存された認証情報が侵害されるリスクが軽減されます。

各外部 IdP には、OpenStack Identity サービス (keystone) ドメインへの 1 対 1 のマッピングがあります。Red Hat OpenStack Platform では複数のドメインを共存させることができます。

外部認証は、追加の ID を作成することなく、既存の認証情報を使用して Red Hat OpenStack Platform のリソースにアクセスする方法を提供します。認証情報は、ユーザーの IdP によって維持されます。

ID 管理には、Red Hat Identity Management (IdM) や Microsoft Active Directory Domain Services (AD DS) などの IdP を使用できます。この設定では、OpenStack Identity サービスには LDAP ユーザーデータベースへの読み取り専用アクセス権があります。ユーザーまたはグループのロールに基づく API アクセスの管理は、keystone によって実行されます。ロールは、OpenStack Identity サービスを使用して LDAP アカウントに割り当てられます。

4.5.1. LDAP 統合の仕組み

以下の図では、keystone は暗号化された LDAPS 接続を使用して Active Directory Domain Controller に接続します。ユーザーが horizon にログインすると、keystone は指定したユーザー認証情報を受け取り、Active Directory に渡します。

ad 統合 keystone v3

第5章 ポリシー

各 OpenStack サービスには、アクセスポリシーで管理されるリソースが含まれています。たとえば、リソースには以下の関数が含まれる場合があります。

  • インスタンスを作成して起動するパーミッション
  • インスタンスにボリュームを接続する機能

Red Hat OpenStack Platform (RHOSP) 管理者は、カスタムポリシーを作成して、さまざまなアクセスレベルで新しいロールを導入することや、既存のロールのデフォルト動作を変更することができます。

重要

Red Hat は、カスタマイズされたロールとポリシーをサポートしていません。構文エラーが発生すると、ダウンタイムが発生し、誤って認証が適用されないとセキュリティーやユーザービリティーに悪影響を及ぼす可能性があります。実稼働環境でカスタムポリシーが必要な場合には、サポート例外について Red Hat サポートにお問い合わせください。

5.1. 既存のポリシーの確認

サービスのポリシーファイルはこれまで /etc/$service ディレクトリーに存在していました。たとえば、Compute (nova) の policy.json ファイルの完全パスは /etc/nova/policy.json でした。

既存のポリシーを見つける方法に影響を与える重要なアーキテクチャーの変更には、以下の 2 つがあります。

  • Red Hat OpenStack Platform はコンテナー化されています。

    • サービスコンテナーからポリシーファイルを確認する場合は、ポリシーファイル (ある場合) は従来のパスにあります。

      /etc/$service/policy.json

    • サービスコンテナーの外部からそれらを表示する場合は、以下のパスに配置されます。

      /var/lib/config-data/puppet-generated/$service/etc/$service/policy.json

  • 各サービスには、コードで提供されるデフォルトのポリシーがあります。これは、手動で作成した場合にのみ利用できるファイル、または oslopolicy ツールで生成された場合に限ります。ポリシーファイルを生成するには、以下の例のように、コンテナーから oslopolicy-policy-generator を使用します。

    podman exec -it keystone oslopolicy-policy-generator --namespace keystone

デフォルトでは、生成されたポリシーは oslo.policy CLI ツールにより stdout にプッシュされます。

5.2. サービスポリシーについて

サービスポリシーファイルステートメントは、エイリアス定義またはルールです。エイリアスの定義はファイルの先頭に存在します。以下のリストには、Compute (nova) 用に生成された policy.json ファイルからのエイリアス定義の説明が記載されています。

  • "context_is_admin": "role:admin"

    ターゲットの後に rule:context_is_admin が表示されたら、そのアクションを許可する前にユーザーが管理コンテキストで動作していることを確認します。

  • "admin_or_owner": "is_admin:True or project_id:%(project_id)s"

    ターゲットの後に admin_or_owner が表示されると、ポリシーはそのユーザーが admin であるか、プロジェクト ID がターゲットオブジェクトの独自のプロジェクト ID と一致することを確認してからそのアクションを許可します。

  • "admin_api": "is_admin:True

    ターゲットの後に admin_api が表示されると、ポリシーはそのアクションを許可する前にそのユーザーが admin であることをチェックします。

5.3. ポリシー構文

Policy.json ファイルは特定のオペレーターをサポートするので、これらの設定のターゲットスコープを制御できます。たとえば、以下の keystone の設定には、ユーザー作成の管理ユーザーだけがルールが含まれます。

"identity:create_user": "rule:admin_required"

: 文字の左側にあるセクションでは、特権について説明し、右側のセクションは、特権を使用できるユーザーを定義します。右側にオペレーターを使用して、スコープをさらに制御することもできます。

  • !: このアクションを実行するユーザー (admin を含む) はありません。
  • @ および "": 任意のユーザーがこのアクションを実行できます。
  • notandor: 標準の Operator 機能を利用できます。

たとえば、以下の設定は、新規ユーザーを作成するパーミッションを持たないことを意味します。

"identity:create_user": "!"

5.4. アクセス制御でのポリシーファイルの使用

重要

Red Hat では、カスタマイズされたロールまたはポリシーはサポートしていません。構文エラーや、承認が誤って適用されると、セキュリティーやユーザービリティーに悪影響を及ぼす可能性があります。実稼働環境でカスタマイズされたロールまたはポリシーが必要な場合は、サポート例外について Red Hat サポートにお問い合わせください。

デフォルトのルールを上書きするには、適切な OpenStack サービスの policy.json ファイルを編集します。たとえば、Compute サービスには nova ディレクトリーに policy.json があります。これは、コンテナーから表示する際にコンテナー化されたサービスの正しい場所となります。

注記
  • ステージング環境でポリシーファイルへの変更をよくテストしてから、それらを実稼働環境で実装する必要があります。
  • アクセス制御ポリシーへの変更が、リソースのセキュリティーを意図せずに脆弱化しないことを確認する必要があります。また、policy.json ファイルへの変更はすぐに有効であり、サービスの再起動は必要ありません。

例: パワーユーザーロールの作成

keystone ロールのパーミッションをカスタマイズするには、サービスの policy.json ファイルを更新します。これは、ユーザーのクラスに割り当てるパーミッションをより詳細に定義できることを意味します。以下の例では、以下の特権を使用してデプロイメントの power user ロールを作成します。

  • インスタンスを起動するには、以下のコマンドを実行します。
  • インスタンスを停止します。
  • インスタンスに割り当てられているボリュームを管理します。

このロールの意図は、admin アクセスを付与せずに、特定のユーザーに追加のパーミッションを付与することです。これらの特権を使用するには、以下のパーミッションをカスタムロールに付与する必要があります。

  • インスタンスを起動する: "os_compute_api:servers:start": "role:PowerUsers"
  • インスタンスを停止する: "os_compute_api:servers:stop": "role:PowerUsers"
  • 特定のボリュームを使用するようにインスタンスを設定する: "os_compute_api:servers:create:attach_volume": "role:PowerUsers"
  • インスタンスに割り当てられているボリュームをリスト表示する: "os_compute_api:os-volumes-attachments:index": "role:PowerUsers"
  • ボリュームを割り当てる: "os_compute_api:os-volumes-attachments:create": "role:PowerUsers"
  • 割り当てられたボリュームの詳細を表示する: "os_compute_api:os-volumes-attachments:show": "role:PowerUsers"
  • インスタンスに割り当てられているボリュームを変更する: "os_compute_api:os-volumes-attachments:update": "role:PowerUsers"
  • インスタンスに割り当てられているボリュームを削除する: "os_compute_api:os-volumes-attachments:delete": "role:PowerUsers"
注記

policy.json ファイルを変更すると、デフォルトのポリシーを上書きします。その結果、PowerUsers のメンバーは、これらのアクションを実行できる唯一のユーザーになります。admin ユーザーがこれらのパーミッションを保持できるようにするには、admin_or_power_user. のルールを作成できます。また、基本的な条件ロジックを使用して role:PowerUsers or role:Admin を定義することもできます。

  1. カスタム keystone ロールを作成します。

    $ openstack role create PowerUsers
    +-----------+----------------------------------+
    | Field     | Value                            |
    +-----------+----------------------------------+
    | domain_id | None                             |
    | id        | 7061a395af43455e9057ab631ad49449 |
    | name      | PowerUsers                      |
    +-----------+----------------------------------+
  2. 既存のユーザーをロールに追加し、ロールをプロジェクトに割り当てます。

    $ openstack role add --project [PROJECT_NAME] --user [USER_ID] [PowerUsers-ROLE_ID]
    注記

    ロールの割り当ては、1 つのプロジェクトのみとペアになります。つまり、ロールをユーザーに割り当てると、ターゲットプロジェクトも同時に定義します。ユーザーが同じロールを受信し、別のプロジェクトを対象にする場合は、ロールを別々に割り当てる必要がありますが、別のプロジェクトが対象となります。

  3. デフォルトの nova ポリシー設定を表示します。

    $ oslopolicy-policy-generator --namespace nova
  4. 以下のエントリーを /var/lib/config-data/puppet-generated/nova/etc/nova/policy.json に追加して、新しい PowerUsers ロールのカスタムパーミッションを作成します。

    注記

    デプロイメント前にポリシーの変更をテストし、想定通りに機能していることを確認します。

    {
    "os_compute_api:servers:start": "role:PowerUsers",
    "os_compute_api:servers:stop": "role:PowerUsers",
    "os_compute_api:servers:create:attach_volume": "role:PowerUsers",
    "os_compute_api:os-volumes-attachments:index": "role:PowerUsers",
    "os_compute_api:os-volumes-attachments:create": "role:PowerUsers",
    "os_compute_api:os-volumes-attachments:show": "role:PowerUsers",
    "os_compute_api:os-volumes-attachments:update": "role:PowerUsers",
    "os_compute_api:os-volumes-attachments:delete": "role:PowerUsers"
    }

    このファイルを保存して nova コンテナーを再起動する際に、変更を実装する。PowerUsers keystone ロールに追加したユーザーは、これらの権限を受信します。

5.5. 例: 属性に基づくアクセスの制限

重要

Red Hat では、カスタマイズされたロールまたはポリシーはサポートしていません。構文エラーや、承認が誤って適用されると、セキュリティーやユーザービリティーに悪影響を及ぼす可能性があります。実稼働環境でカスタマイズされたロールまたはポリシーが必要な場合は、サポート例外について Red Hat サポートにお問い合わせください。

API 呼び出しを実行するユーザーの属性に基づいて、API 呼び出しへのアクセスを制限するポリシーを作成できます。たとえば、以下のデフォルトのルールは、管理者コンテキストから実行された場合のキーペアの削除が許可されるか、トークンのユーザー ID がターゲットに関連付けられたユーザー ID と一致することを示しています。

"os_compute_api:os-keypairs:delete": "rule:admin_api or user_id:%(user_id)s"

注記: *新しい実装機能は、各リリースと共に各サービスに保証される訳ではありません。したがって、ターゲットサービスの既存のポリシーの規則を使用してルールを作成することが重要です。これらのポリシーの表示に関する詳細は、既存ポリシーの確認を参照してください。* すべてのポリシーは、リリース間の互換性の保証が保証されないため、デプロイするすべてのバージョンの非実稼働環境でテストする必要があります。

上記の例では、API ルールを作成し、リソースを所有するかどうかに基づいてユーザーへのアクセスを拡張または制限できます。また、属性と他の制限を組み合わせて、以下の例で示すようにルールを形成できます。

"admin_or_owner": "is_admin:True or project_id:%(project_id)s"

上記の例を考慮すると、管理者およびユーザーに限定した一意のルールを作成し、そのルールを使用してさらにアクションを制限することができます。

"admin_or_user": "is_admin:True or user_id:%(user_id)s"
"os_compute_api:os-instance-actions": "rule:admin_or_user"

利用可能な policy.json 構文オプションの詳細は、ポリシー構文 を参照してください。

5.6. Heat でのポリシーの変更

重要

Red Hat では、カスタマイズされたロールまたはポリシーはサポートしていません。構文エラーや、承認が誤って適用されると、セキュリティーやユーザービリティーに悪影響を及ぼす可能性があります。実稼働環境でカスタマイズされたロールまたはポリシーが必要な場合は、サポート例外について Red Hat サポートにお問い合わせください。

heat を使用して、オーバークラウド内の特定のサービスのアクセスポリシーを設定できます。次のパラメーターを使用して、それぞれのサービスにポリシーを設定します。

表5.1 ポリシーパラメーター

パラメーター説明

KeystonePolicies

OpenStack Identity (keystone) 向けに設定するポリシーのハッシュ

IronicApiPolicies

OpenStack Bare Metal (ironic) API 向けに設定するポリシーのハッシュ

BarbicanPolicies

OpenStack Key Manager (barbican) 向けに設定するポリシーのハッシュ

NeutronApiPolicies

OpenStack Networking (neutron) API 向けに設定するポリシーのハッシュ

SaharaApiPolicies

OpenStack Clustering (sahara) API 向けに設定するポリシーのハッシュ

NovaApiPolicies

OpenStack Compute (nova) API 向けに設定するポリシーのハッシュ

CinderApiPolicies

OpenStack Block Storage (cinder) API 向けに設定するポリシーのハッシュ

GlanceApiPolicies

OpenStack Image Storage (glance) API 向けに設定するポリシーのハッシュ

HeatApiPolicies

OpenStack Orchestration (heat) API 向けに設定するポリシーのハッシュ

サービスのポリシーを設定するには、サービスのポリシーを含むハッシュ値をポリシーパラメーターに指定します。次に例を示します。

  • OpenStack Identity (keystone) には KeystonePolicies パラメーターを使用します。このパラメーターを環境ファイルの parameter_defaults セクションで設定します。

    parameter_defaults:
      KeystonePolicies: { keystone-context_is_admin: { key: context_is_admin, value: 'role:admin' } }
  • OpenStack Compute (nova) には NovaApiPolicies パラメーターを使用します。このパラメーターを環境ファイルの parameter_defaults セクションで設定します。

    parameter_defaults:
      NovaApiPolicies: { nova-context_is_admin: { key: 'compute:get_all', value: '@' } }

5.7. ユーザーおよびロールの監査

Red Hat OpenStack Platform で利用可能なツールを使用して、ユーザーおよび関連付けられた権限ごとのロール割り当てのレポートをビルドできます。

  1. openstack role list コマンドを実行して、環境内の現在ロールを表示します。

    openstack role list -c Name -f value
    
    swiftoperator
    ResellerAdmin
    admin
    _member_
    heat_stack_user
  2. openstack role assignment list コマンドを実行して、特定のロールのメンバーであるすべてのユーザーをリスト表示します。たとえば、admin ロールを持つユーザーを確認するには、以下を実行します。

    $ openstack role assignment list --names --role admin
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    | Role  | User                               | Group | Project         | Domain     | System | Inherited |
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    | admin | heat-cfn@Default                   |       | service@Default |            |        | False     |
    | admin | placement@Default                  |       | service@Default |            |        | False     |
    | admin | neutron@Default                    |       | service@Default |            |        | False     |
    | admin | zaqar@Default                      |       | service@Default |            |        | False     |
    | admin | swift@Default                      |       | service@Default |            |        | False     |
    | admin | admin@Default                      |       | admin@Default   |            |        | False     |
    | admin | zaqar-websocket@Default            |       | service@Default |            |        | False     |
    | admin | heat@Default                       |       | service@Default |            |        | False     |
    | admin | ironic-inspector@Default           |       | service@Default |            |        | False     |
    | admin | nova@Default                       |       | service@Default |            |        | False     |
    | admin | ironic@Default                     |       | service@Default |            |        | False     |
    | admin | glance@Default                     |       | service@Default |            |        | False     |
    | admin | mistral@Default                    |       | service@Default |            |        | False     |
    | admin | heat_stack_domain_admin@heat_stack |       |                 | heat_stack |        | False     |
    | admin | admin@Default                      |       |                 |            | all    | False     |
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    注記

    -f {csv,json,table,value,yaml} パラメーターを使用して、これらの結果をエクスポートできます。

5.8. API アクセスの監査

所定のロールがアクセスできる API 呼び出しを監査できます。各ロールに対してこのプロセスを繰り返すと、各ロールのアクセス可能な API に包括的なレポートが実行されます。以下の手順には、以下が必要です。

  • ターゲットロールのユーザーとしてソースとする認証ファイル。
  • JSON 形式のアクセストークン
  • 監査する各サービスの API のポリシーファイル。

手順

  1. 次に、必要なロールでユーザーの認証ファイルを一時停止します。
  2. Keystone 生成されたトークンを取得し、ファイルに保存します。そのためには、openstack-cli コマンドを実行し、--debug オプションを指定して、指定したトークンを stdout に出力します。このトークンをコピーして、アクセスファイルに保存できます。このコマンドを 1 つのステップとして実行します。

    openstack token issue --debug 2>&1 | egrep ^'{\"token\":' > access.file.json
  3. ポリシーファイルを作成します。これは、コンテナー化されたサービスをホストするオーバークラウドノード上で実行できます。以下の例では、cinder サービスのポリシーファイルを作成します。

    ssh heat-admin@CONTROLLER-1 sudo podman exec cinder_api \
    oslopolicy-policy-generator \
    --config-file /etc/cinder/cinder.conf \
    --namespace cinder > cinderpolicy.json
  4. これらのファイルを使用して、cinder の API にアクセスするための対象のロールを監査できるようになりました。

    oslopolicy-checker --policy cinderpolicy.json --access access.file.json

第6章 サービスアカウントパスワードのローテーション

定期的にサービスアカウントパスワードをローテーションして、セキュリティーに関する操作を向上できます。

6.1. オーバークラウドのパスワード管理の概要

オーバークラウド上で実行する OpenStack サービスは、Identity サービス (keystone) の認証情報により認証されます。これらのパスワードは、初期のデプロイメントプロセス時に生成され、heat パラメーターとして定義されます。以下に例を示します。

            'MistralPassword',
            'BarbicanPassword',
            'AdminPassword',
            'CeilometerMeteringSecret',
            'ZaqarPassword',
            'NovaPassword',
            'MysqlRootPassword'

Workflow サービス (mistral) ワークフローを使用して、サービスアカウントが使用するパスワードをローテーションできます。ただし、Key Encrypting Keys(KEK) キーおよび Fernet キーなど、DO_NOT_ROTATE に記載のパスワードがローテーションされません。

DO_NOT_ROTATE_LIST = (
    'BarbicanSimpleCryptoKek',
    'SnmpdReadonlyUserPassword',
    'KeystoneCredential0',
    'KeystoneCredential1',
    'KeystoneFernetKey0',
    'KeystoneFernetKey1',
    'KeystoneFernetKeys',
)

これらのパスワードは、以下の理由により DO_NOT_ROTATE リストにあります。

  • DO_NOT_ROTATE: このパスワードを変更するには、すべてのシークレットを再暗号化する必要があります。
  • KeystoneFernetKey および KeystoneCredential: これらのワークフローをローテーションするためにすでに別のワークフローが存在します。詳細は、Rotating the Fernet keys by using the Workflow service を参照してください。

6.2. パスワードのローテーション

以下の手順を使用して、対象のパスワードをローテーションします。次回 openstack overcloud deploy コマンドを実行してスタックの更新を完了すると、ローテーションされたパスワードの変更が適用されます。環境ファイルで指定したパスワードは、この方法を使用するパスワードの変更よりも優先されます。要件およびサービスへの影響に関する情報は、Outage requirements を参照してください。

重要

現在サポートされていないため、この手順を使用して swift パスワードをローテーションしないでください。

  1. stack ユーザーとして、パスワードのローテーションワークフローを実行します。これにより、DO_NOT_ROTATE リストにあるパスワード以外はすべてローテーションされます。

    $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud"}'

    特定のパスワードだけをローテーションする場合は、password_list を使用することができます。この方法を使用して、DO_NOT_ROTATE リストでパスワードをローテーションすることもできます。以下に例を示します。

    $ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud", "password_list": ["SaharaPassword", "ManilaPassword"]}'
    The Workflow service Mistral workflow generates new passwords for the service accounts.
  2. スタック更新を実行して新規パスワードを適用します。
  3. パスワードを取得して、出力を表示するワークフローを作成して、新しいパスワードを取得して表示できます。

    1. パスワードを取得するための新しいワークフローを作成します。ワークフローの ID をメモします。

      $ openstack workflow execution create tripleo.plan_management.v1.get_passwords '{"container": "overcloud"}'
       +--------------------+---------------------------------------------+
       | Field              | Value                                       |
       +--------------------+---------------------------------------------+
       | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
       | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
       | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
       | Workflow namespace |                                             |
       | Description        |                                             |
       | Task Execution ID  | <none>                                      |
       | Root Execution ID  | <none>                                      |
       | State              | RUNNING                                     |
       | State info         | None                                        |
       | Created at         | 2020-01-22 15:47:57                         |
       | Updated at         | 2020-01-22 15:47:57                         |
       +--------------------+---------------------------------------------+
    2. ワークフロー ID を使用してワークフローのステータスを確認します。ワークフローの状態が SUCCESS になるまで待機してから続行します。

      $ openstack workflow execution show edcf9103-e1a8-42f9-85c1-e505c055e0ed
            +--------------------+---------------------------------------------+
            | Field              | Value                                       |
            +--------------------+---------------------------------------------+
            | ID                 | edcf9103-e1a8-42f9-85c1-e505c055e0ed        |
            | Workflow ID        | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a        |
            | Workflow name      | tripleo.plan_management.v1.rotate_passwords |
            | Workflow namespace |                                             |
            | Description        |                                             |
            | Task Execution ID  | <none>                                      |
            | Root Execution ID  | <none>                                      |
            | State              | SUCCESS                                     |
            | State info         | None                                        |
            | Created at         | 2020-01-22 15:47:57                         |
            | Updated at         | 2020-01-22 15:48:39                         |
            +--------------------+---------------------------------------------+
    3. ワークフローが完了したら、以下のコマンドを使用してパスワードを取得します。

      openstack workflow execution output show edcf9103-e1a8-42f9-85c1-e505c055e0ed
           {
                "status": "SUCCESS",
                "message": {
                    "AdminPassword": "FSn0sS1aAHp8YK2fU5niM3rxu",
                    "AdminToken": "dTP0Wdy7DtblG80M54r4a2yoC",
                    "AodhPassword": "fB5NQdRe37BaBVEWDHVuj4etk",
                    "BarbicanPassword": "rn7yk7KPafKw2PWN71MvXpnBt",
                    "BarbicanSimpleCryptoKek": "lrC3sGlV7-D7-V_PI4vbDfF1Ujm5OjnAVFcnihOpbCg=",
                    "CeilometerMeteringSecret": "DQ69HdlJobhnGWoBC0jM3drPF",
                    "CeilometerPassword": "qI6xOpofuiXZnG95iUe8Oxv5d",
                    "CephAdminKey": "AQDGVPpdAAAAABAAZMP56/VY+zCVcDT81+TOjg==",
                    "CephClientKey": "AQDGVPpdAAAAABAAanYtA0ggpcoCbS1nLeDN7w==",
                    "CephClusterFSID": "141a5ede-21b4-11ea-8132-52540031f76b",
                    "CephDashboardAdminPassword": "AQDGVPpdAAAAABAAKhsx630YKDhQrocS4o4KzA==",
                    "CephGrafanaAdminPassword": "AQDGVPpdAAAAABAAKBojG+CO72B0TdBRR0paEg==",
                    "CephManilaClientKey": "AQDGVPpdAAAAABAAA1TVHrTVCC8xQ4skG4+d5A=="
                }
            }

6.3. 停止の要件

オーバークラウドサービスアカウントのパスワードを変更すると、停止要件とサービスへの影響が発生することがあります。

スタック更新の一環としてパスワードをローテーションした後、古いパスワードが無効になります。その結果、サービス設定に新しいパスワードを追加するまでに、HTTP 401 エラーでサービスが利用できなくなります。

さらに、MySQL、RabbitMQ、および高可用性など、サポートサービスのパスワードを変更すると、一時的に停止することが予想されます。

第7章 ネットワークタイムプロトコル

Red Hat OpenStack Platform クラスター内のシステムが、システム間で正確かつ一貫性のあるタイムスタンプを持つことを確認する必要があります。

Red Hat Enterprise Linux 8 上の Red Hat OpenStack Platform は、時間管理に Chrony をサポートしています。詳細は、Chrony スイートを使用した NTP の設定 を参照してください。

7.1. 一貫した時刻が重要な理由

運用とセキュリティー上のニーズの両方で、組織全体で時刻が一貫していることが重要です。

セキュリティーイベントの特定
一貫した時刻を維持することにより、影響を受けるシステムのイベントのタイムスタンプを関連付けることができ、イベントのシーケンスを理解することができます。
認証システムおよびセキュリティーシステム

セキュリティーシステムは、以下の例のように、時刻のずれの影響を受ける場合があります。

  • Kerberos ベースの認証システムは、時刻のずれの秒数により影響を受けるクライアントの認証を拒否する可能性があります。
  • トランスポート層セキュリティー (TLS) 証明書は、有効な時刻ソースに依存します。クライアントとサーバーシステム間の差異が Valid From の日付範囲を超えると、クライアントからサーバーへの TLS 接続が失敗します。
Red Hat OpenStack Platform のサービス
高可用性 (HA) や Ceph など、一部の OpenStack のコアサービスは、特に正確な時刻管理に依存しています。

7.2. NTP 設計

Network time protocol (NTP) は、階層的な設定で整理されています。各レイヤーは stratum と呼ばれます。階層の最上位は、原子時計などの stratum 0 デバイスです。NTP 階層では、Stratum 0 デバイスは、一般に利用可能な stratum 1 および stratum 2 の NTP 時刻サーバーに参照を提供します。

データセンタークライアントは、一般に利用可能な NTP stratum 1 または 2 サーバーに直接接続しないでください。直接接続の数は、パブリック NTP リソースに不必要な負荷をかけます。代わりに、データセンターで専用の時刻サーバーを割り当て、クライアントをその専用サーバーに接続します。

インスタンスがホストではなく専用の時刻サーバーから時刻を受信するように設定します。

注記

Red Hat OpenStack Platform 環境内で実行中のサービスコンテナーは、それらのサービスが存在するホストから時刻を受信します。

第8章 インフラストラクチャーおよび仮想化の強化

ハードウェアとソフトウェアのベンダーに定期的に確認して、新しい脆弱性とセキュリティー更新プログラムに関して提供されている情報を入手してください。Red Hat Product Security は、以下のサイトを管理し、セキュリティー更新をお知らせします。

Red Hat OpenStack Platform のデプロイメントを定期的に更新する場合には、次の点に注意してください。

  • すべてのセキュリティー更新が含まれていることを確認する。
  • カーネルの更新には再起動が必要である。
  • ホストされている Image Service (glance) のイメージを更新して、新しく作成されたインスタンスに最新の更新が適用されるようにする。

8.1. Hypervisors

ハイパーバイザープラットフォームを評価する際には、ハイパーバイザーを実行するハードウェアのサポート可能性を考慮してください。また、ハードウェアで利用可能な追加機能と、それらの機能が OpenStack デプロイメントの一部として選択したハイパーバイザーによってどのようにサポートされているかについて検討してください。そのため、ハイパーバイザーには、それぞれ独自のハードウェア互換性リスト (HCL) があります。互換性のあるハードウェアを選択する場合は、セキュリティーの観点から、ハードウェアベースの仮想化技術が重要なかを把握しておくことが重要です。

8.1.1. ハイパーバイザーとベアメタル

Linux コンテナーまたはベアメタルシステムの使用と KVM のようなハイパーバイザーの使用の違いを認識しておくことは重要です。具体的には、このセキュリティーガイドは、ハイパーバイザーと仮想化プラットフォームに非常に重点を置いています。ただし、実装にベアメタルまたはコンテナー化環境を使用する必要がある場合は、その環境のデプロイメントに関して、特定の違いに注意する必要があります。

ベアメタルの場合は、再プロビジョニングして使用を停止する前に、ノードが正しくデータがサニタイズされていることを確認します。また、ノードを再使用する前に、ハードウェアが改ざんされていないか、セキュリティーが侵害されていないことを保証する必要があります。詳細は https://docs.openstack.org/ironic/queens/admin/cleaning.htmlを参照してください。

8.1.2. ハイパーバイザーメモリーの最適化

特定のハイパーバイザーは、メモリーをゲスト仮想マシンにオーバーコミットするメモリー最適化手法を使用します。これは、非常に高密度のコンピュートクラスターをデプロイすることができる便利な機能です。この手法の 1 つは、メモリーページの重複排除または共有により、メモリーページに 2 つの仮想マシンが同じデータがある場合、同じメモリーを参照する利点があります。これは通常、カーネル same-page merging (KSM) などの Copy-On-Write (COW) メカニズムで実行されます。これらのメカニズムは攻撃に対して脆弱です。

  • メモリーの重複排除システムは、サイドチャネル攻撃に対して脆弱です。攻撃者は、近傍の仮想マシンで実行しているソフトウェアパッケージとバージョンを特定し、攻撃者が仮想マシンのメモリーアクセス時間を分析することで、ソフトウェアのダウンロードやその他の機密情報を特定できていました。そのため、ある仮想マシンは別の状態に関するものを推測できます。これは、すべてのプロジェクトが信頼される場合や、同じ信頼レベルを共有することができない複数プロジェクト環境には適していない可能性があります。
  • さらに重要なことは、KSM に対して row-hammer タイプ攻撃 を参照して、実行可能なメモリーのクロス修正を行います。つまり、悪意のあるインスタンスが、同じ Compute ホスト上の他のインスタンスへのコード実行アクセスを取得できることを意味します。

Deployer は、(パブリッククラウドやプライベートクラウドを使用して) 強力なプロジェクトの分離が必要な場合は、KSM を無効にする必要があります。

8.2. PCI パススルー

PCI パススルーを使用すると、インスタンスはノード上のハードウェアの一部に直接アクセスできます。たとえば、このパラメーターを使用して、インスタンスをビデオカードや GPU にアクセスできるようにし、高パフォーマンスの計算用にコンピュート統一されたデバイスアーキテクチャー (CUDA) を提供します。この機能は、ダイレクトメモリーアクセスとハードウェアの脆弱性の 2 種類のセキュリティーリスクを伴います。

ダイレクトメモリーアクセス (DMA) は、特定のハードウェアデバイスがホストコンピューター内の任意の物理メモリーアドレスにアクセスできるようにする機能です。多くの場合、ビデオカードにはこの機能があります。ただし、これにより、同じノードで実行されているホストシステムや他のインスタンスの両方を確認することがあるため、任意の物理メモリーアクセスを付与しないでください。ハードウェアベンダーは、出入力メモリー管理ユニット (IOMMU) を使用して、このような状況で DMA アクセスを管理します。ハイパーバイザーがこのハードウェア機能を使用するように設定されていることを確認する必要があります。

インスタンスがファームウェアや他のデバイスの一部に悪意のある変更を加えると、ハードウェア感染が発生します。他のインスタンスやホスト OS がこのデバイスが使用されるため、悪意のあるコードはこれらのシステムに配布できます。最終的には、あるインスタンスがそのセキュリティーゾーン外でコードを実行できることです。これは、仮想ハードウェアよりも物理ハードウェアの状態をリセットすることが難しくなるため、管理ネットワークへのアクセスなどが追加で公開される可能性があるためです。

PCI パススルーに関連するリスクおよび複雑性により、デフォルトでは無効になっています。特定のニーズに応じて有効になっている場合は、ハードウェアを再利用する前に、ハードウェアがクリーンアップされるように適切なプロセスを用意する必要があります。

8.3. Red Hat OpenStack Platform 上の Selinux

SELinux (Security-Enhanced Linux) は、強制アクセス制御 (MAC) の実装です。MAC は、プロセスまたはアプリケーションがシステム上で実行できることを制限することにより、攻撃の影響を制限します。SELinux の詳細は、SELinux とは を参照してください。.

Red Hat OpenStack Platform (RHOSP) サービス用に SELinux ポリシーが事前設定されています。RHOSP では、SELinux は、個別のセキュリティーコンテキストで各 QEMU プロセスを実行するように設定されます。RHOSP では、SELinux ポリシーはハイパーバイザーのホストとインスタンスを次の脅威から保護するのに役立ちます。

ハイパーバイザーの脅威
インスタンス内で実行している侵害されたアプリケーションは、ハイパーバイザーを攻撃して、基盤となるリソースにアクセスします。インスタンスがハイパーバイザー OS にアクセスできる場合は、物理デバイスやその他のアプリケーションがターゲットになる可能性があります。この脅威は、かなりのリスクを表しています。ハイパーバイザーが侵害されると、ファームウェア、他のインスタンス、およびネットワークリソースも侵害される可能性があります。
インスタンスの脅威
インスタンス内で実行されている侵害されたアプリケーションは、ハイパーバイザーを攻撃して、別のインスタンスとそのリソース、またはインスタンスファイルイメージにアクセスまたは制御します。実際のネットワークを保護するための管理戦略は、仮想環境には直接適用されません。すべてのインスタンスは SELinux によってラベル付けされたプロセスであるため、Linux カーネルによって適用される各インスタンスの周りにセキュリティー境界があります。

RHOSP では、ディスク上のインスタンスイメージファイルは SELinux データ型 svirt_image_t でラベル付けされます。インスタンスの電源がオンになると、SELinux はランダムな数値識別子をイメージに追加します。ランダムな数値識別子により、侵害された OpenStack インスタンスが他のコンテナーへの不正アクセスを取得するのを防ぐことができます。SELinux は、各ハイパーバイザーノードに最大 524,288 個の数値識別子を割り当てることができます。

8.4. コンテナー化されたサービスの調査

Red Hat OpenStack Platform に付属する OpenStack サービスは、コンテナー内で実行されます。コンテナー化により、依存関係に関連する競合なしでサービスの開発とアップグレードが可能になります。サービスがコンテナー内で実行される場合、そのサービスに対する潜在的な脆弱性も含まれます。

次の手順を使用して、環境で実行されているサービスに関する情報を取得できます。

手順

  • `podman inspect を使用して、マウントされたホストディレクトリーのバインドなどの情報を取得します。

    以下に例を示します。

    $ sudo podman inspect <container_name> | less

    <container_name> をコンテナーの名前に置き換えます。たとえば、nova compute です。

  • /var/log/containers にあるサービスのログを確認します。

    以下に例を示します。

    sudo less /var/log/containers/nova/nova-compute.log
  • コンテナー内で対話型 CLI セッションを実行します。

    以下に例を示します。

    podman exec -it nova_compute /bin/bash
    注記

    コンテナー内で直接、テスト目的でサービスに変更を加えることができます。コンテナーを再起動すると、すべての変更が失われます。

8.5. コンテナー化されたサービスに一時的な変更を加える

コンテナーが再起動されても維持されるが、Red Hat OpenStack Platform (RHOSP) クラスターの永続的な設定には影響しない、コンテナー化されたサービスに変更を加えることができます。これは、設定の変更をテストしたり、トラブルシューティング時にデバッグレベルのログを有効にしたりするのに役立ちます。変更を手動で元に戻すことができます。または、RHOSP クラスターで再デプロイを実行すると、すべてのパラメーターが永続的な設定にリセットされます。

/var/lib/config-data/puppet-generated/service にある設定ファイルを使用して、サービスに一時的な変更を加えます。次の例では、nova サービスでデバッグを有効にします。

手順

  1. nova_compute コンテナーにバインドマウントされている nova.conf 設定ファイルを編集します。debug パラメーターの値を True に設定します。

    $ sudo sed -i 's/^debug=.*/debug=True' \
    /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf
    警告

    OpenStack ファイルの設定ファイルは、DEFAULT[database] などの複数のセクションを持つ ini ファイルです。各セクションに固有のパラメーターは、ファイル全体で固有ではない場合があります。sed は慎重に使用してください。egrep -v "^$|^#" [configuration_file] | grep [parameter] を実行して、parameter が設定ファイルに複数回出現するかどうかを確認できます。

  2. nova コンテナーを再起動します。

    sudo podman restart nova_compute

8.6. コンテナー化されたサービスに永続的な変更を加える

Heat を使用して、Red Hat OpenStack Platform (RHOSP) サービスのコンテナー化されたサービスに永続的な変更を加えることができます。最初に RHOSP をデプロイしたときに使用した既存のテンプレートを使用するか、新しいテンプレートを作成してデプロイスクリプトに追加します。次の例では、libvirt の秘密鍵のサイズを 4096 に増やしています。

手順

  1. libvirt-keysize.yaml という新しい yaml テンプレートを作成し、LibvirtCertificateKeySize パラメーターを使用してデフォルト値を 2048 から 4096 に増やします。

    cat > /home/stack/templates/libvirt-keysize.yaml
    parameter_defaults:
            LibvirtCertificateKeySize: 4096
    EOF
  2. libvirt-keysize.yaml 設定ファイルをデプロイスクリプトに追加します。

    openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/libvirt-keysize.yaml
    ...
  3. デプロイスクリプトを再実行します。

    ./deploy.sh

8.7. ファームウェアの更新

物理サーバーは複雑なファームウェアを使用して、サーバーのハードウェアと軽量な管理カードを有効にして操作します。このカードでは、独自のセキュリティー脆弱性を持つことができ、システムアクセスと中断が可能になります。これに対処するために、ハードウェアベンダーは、オペレーティングシステムの更新とは別にインストールされるファームウェアの更新を発行します。この更新を取得、テスト、および実装する運用セキュリティープロセスが必要になります。ファームウェアの更新では多くの場合で、物理ホストの再起動が効果的に行われるためです。

8.8. SSH バナーテキストの使用

SSH 経由で接続する全ユーザーにコンソールメッセージを表示するバナーを設定できます。環境ファイルの以下のパラメーターを使用して、/etc/issue にバナーテキストを追加できます。実際の要件に合わせて、このサンプルテキストをカスタマイズすることを検討してください。

resource_registry:
  OS::TripleO::Services::Sshd:
    /usr/share/openstack-tripleo-heat-templates/deployment/sshd/sshd-baremetal-puppet.yaml

parameter_defaults:
  BannerText: |
   ******************************************************************
   * This system is for the use of authorized users only. Usage of  *
   * this system may be monitored and recorded by system personnel. *
   * Anyone using this system expressly consents to such monitoring *
   * and is advised that if such monitoring reveals possible        *
   * evidence of criminal activity, system personnel may provide    *
   * the evidence from such monitoring to law enforcement officials.*
   ******************************************************************

この変更をデプロイメントに適用するには、設定を ssh_banner.yaml という名前のファイルで保存し、以下のように overcloud deploy コマンドに渡します。<full environment> は、元のデプロイメントパラメーターをすべて含める必要があることを示します。以下に例を示します。

    openstack overcloud deploy --templates \
      -e <full environment> -e  ssh_banner.yaml

8.9. システムイベントの監査

すべての監査イベントの記録を維持すると、システムベースラインの確立、トラブルシューティングの実行、特定の結果の原因となったイベントシーケンスの分析に役立ちます。監査システムは、システム時刻の変更、Mandatory/Discretionary アクセス制御の変更、ユーザーおよびグループの作成や削除など、多数のタイプのイベントをログに記録できます。

環境ファイルを使用してルールを作成し、director がそれを /etc/audit/audit.rules に挿入します。以下に例を示します。

    resource_registry:
      OS::TripleO::Services::AuditD: /usr/share/openstack-tripleo-heat-templates/deployment/auditd/auditd-baremetal-puppet.yaml
    parameter_defaults:
      AuditdRules:
        'Record Events that Modify User/Group Information':
          content: '-w /etc/group -p wa -k audit_rules_usergroup_modification'
          order  : 1
        'Collects System Administrator Actions':
          content: '-w /etc/sudoers -p wa -k actions'
          order  : 2
        'Record Events that Modify the Systems Mandatory Access Controls':
          content: '-w /etc/selinux/ -p wa -k MAC-policy'
          order  : 3

8.10. ファイアウォールルールの管理

ファイアウォールルールは、デプロイメント時にオーバークラウドノードに自動的に適用され、OpenStack の運用に必要なポートのみを公開することを目的としています。必要に応じて、追加のファイアウォールルールを指定できます。たとえば、Zabbix モニタリングシステムのルールを追加するには、以下のようにします。

    parameter_defaults:
      ControllerExtraConfig:
        tripleo::firewall::firewall_rules:
          '301 allow zabbix':
            dport: 10050
            proto: tcp
            source: 10.0.0.8
            action: accept

アクセスを制限するルールを追加することもできます。ルールの定義時に使用される数字は、ルールの優先順位を決定します。たとえば、RabbitMQ のルール番号は、デフォルトでは 109 です。これを抑制するには、小さい数字を使用するように切り替えます。

    parameter_defaults:
      ControllerExtraConfig:
        tripleo::firewall::firewall_rules:
          '098 allow rabbit from internalapi network':
            dport: [4369,5672,25672]
            proto: tcp
            source: 10.0.0.0/24
            action: accept
          '099 drop other rabbit access':
            dport: [4369,5672,25672]
            proto: tcp
            action: drop

この例では、098099 は、RabbitMQ のルール番号 109 よりも小さい任意に選んだ番号です。ルールの番号を確認するには、適切なノードで iptables ルールを検査できます。RabbitMQ の場合は、コントローラーをチェックします。

iptables-save
[...]
-A INPUT -p tcp -m multiport --dports 4369,5672,25672 -m comment --comment "109 rabbitmq" -m state --state NEW -j ACCEPT

または、puppet 定義からポート要件を抽出することもできます。たとえば、RabbitMQ のルールは puppet/services/rabbitmq.yaml に保存されます。

    tripleo.rabbitmq.firewall_rules:
      '109 rabbitmq':
        dport:
          - 4369
          - 5672
          - 25672

ルールには、以下のパラメーターを設定できます。

  • port: ルールに関連付けられたポート。puppetlabs-firewall により非推奨になりました。
  • dport: ルールに関連付けられた宛先ポート
  • sport: ルールに関連付けられた送信元ポート
  • proto: ルールに関連付けられたプロトコル。デフォルトは tcp です。
  • action: ルールに関連付けられたアクションポリシー。デフォルトは accept です。
  • jump: ジャンプ先のチェーン
  • state: ルールに関連付けられた状態の配列。デフォルトは [NEW] です。
  • source: ルールに関連付けられた送信元の IP アドレス
  • iniface: ルールに関連付けられたネットワークインターフェイス
  • chain: ルールに関連付けられたチェーン。デフォルトは INPUT です。
  • destination: ルールに関連付けられた宛先の cidr
  • extras: puppetlabs-firewall モジュールでサポートされる追加パラメーターのハッシュ

8.11. AIDE を使用した侵入検知

AIDE (Advanced Intrusion Detection Environment) は、ファイルとディレクトリーの整合性チェッカーです。これは、承認されていないファイルの改ざんまたは変更のインシデントを検出するために使用されます。たとえば、AIDE は、システムパスワードファイルが変更された場合に警告を出すことができます。

AIDE は、システムファイルを分析し、ファイルハッシュの整合性データベースをまとめることで機能します。次に、データベースは、ファイルとディレクトリーの整合性を検証し、変更を検出する際の比較ポイントとなります。

director には AIDE サービスが含まれており、AIDE 設定にエントリーを追加でき、AIDE サービスはこれを使用して整合性データベースを作成できます。以下に例を示します。

  resource_registry:
    OS::TripleO::Services::Aide:
      /usr/share/openstack-tripleo-heat-templates/deployment/aide/aide-baremetal-ansible.yaml

  parameter_defaults:
    AideRules:
      'TripleORules':
        content: 'TripleORules = p+sha256'
        order: 1
      'etc':
        content: '/etc/ TripleORules'
        order: 2
      'boot':
        content: '/boot/ TripleORules'
        order: 3
      'sbin':
        content: '/sbin/ TripleORules'
        order: 4
      'var':
        content: '/var/ TripleORules'
        order: 5
      'not var/log':
        content: '!/var/log.*'
        order: 6
      'not var/spool':
        content: '!/var/spool.*'
        order: 7
      'not nova instances':
        content: '!/var/lib/nova/instances.*'
        order: 8
注記

上記の例は、積極的には保守やベンチマーク設定されないので、要件に合わせて AIDE の値を選択する必要があります。

  1. TripleORules という名前のエイリアスを宣言することで、毎回同じ属性を繰り返し除外する必要がなくなります。
  2. エイリアスは p+sha256 の属性を受け取ります。AIDE では、これは次の命令として解釈されます。sha256 の整合性チェックサムを使用してすべてのファイルパーミッション p を監視する。

AIDE の設定ファイルで利用可能な属性の完全リストは、AIDE MAN ページ (https://aide.github.io/) を参照してください。

以下の手順を実行して、変更をデプロイメントに適用します。

  1. /home/stack/templates/ ディレクトリーに aide.yaml というファイルとして設定を保存します。
  2. aide.yaml 環境ファイルを編集して、お使いの環境に適したパラメーターおよび値を指定します。
  3. ご自分の環境に固有のその他すべての heat テンプレートおよび環境ファイルと共に、/home/stack/templates/aide.yaml 環境ファイルを openstack overcloud deploy コマンドに追加します。

    openstack overcloud deploy --templates
    ...
    -e /home/stack/templates/aide.yaml

8.11.1. 複雑な AIDE ルールの使用

前述の形式を使用して、複雑なルールを作成できます。以下に例を示します。

    MyAlias = p+i+n+u+g+s+b+m+c+sha512

上記は、次の命令として解釈されます。チェックサムの生成に sha256 を使用して、パーミッション、inode、リンクの数、ユーザー、グループ、サイズ、ブロック数、mtime、ctime をモニターする。

エイリアスの順番の位置は常に 1 であることに注意してください。つまり、AIDE ルールの先頭に配置され、それ以下のすべての値に再帰的に適用されます。

エイリアスの後は、監視するディレクトリーになります。正規表現を使用できます。たとえば、var ディレクトリーの監視を設定しますが、! を使用して not 句で上書きします ('!/var/log.*' および '!/var/spool.*')。

8.11.2. その他の AIDE 値

以下の AIDE 値も使用できます。

AideConfPath: aide 設定ファイルへの完全な POSIX パス。デフォルトは /etc/aide.conf です。ファイルの場所を変更する要件がない場合は、デフォルトのパスのままにすることが推奨されます。

AideDBPath: AIDE 整合性データベースへの完全な POSIX パス。この値は設定が可能で、オペレーターが独自のフルパスを宣言できます。多くの場合、AIDE データベースファイルはノード外に保管されるためです (読み取り専用のファイルマウント)。

AideDBTempPath: AIDE 整合性一時データベースへの完全な POSIX パス。この一時ファイルは、AIDE が新規データベースを初期化する際に作成されます。

AideHour: この値は、AIDE cron 設定の一部として hour 属性を設定します。

AideMinute: この値は、AIDE cron 設定の一部として minute 属性を設定します。

AideCronUser: この値は、AIDE cron 設定の一部として linux ユーザーを設定します。

AideEmail: この値は、cron が実行されるたびに AIDE レポートを受信するメールアドレスを設定します。

AideMuaPath: この値は、AideEmail で設定したメールアドレスに AIDE レポートを送信するために使用される Mail User Agent へのパスを設定します。

8.11.3. AIDE の cron 設定

AIDE director サービスにより、cron ジョブを設定できます。デフォルトでは、レポートを /var/log/audit/ に送信します。メールアラートを使用する場合は、AideEmail パラメーターを有効にして、設定されたメールアドレスにアラートを送信します。重大なアラートをメールに依存することは、システム停止や意図しないメッセージフィルタリングに対して脆弱である可能性があることに注意してください。

8.11.4. システムアップグレードの影響に関する考慮

アップグレードが実行されると、AIDE サービスが新しい整合性データベースを自動的に再生成し、アップグレードしたすべてのファイルが正しく再計算され、更新されたチェックサムが生成されるようにします。

openstack overcloud deploy が初期デプロイメントに対して後続の実行として呼び出され、AIDE 設定ルールが変更されると、director AIDE サービスはデータベースを再構築して、整合性データベースに新規設定属性が取り込まれるようにします。

8.12. SecureTTY の確認

securetty を使用すると、コンソールデバイス (tty) に対する root アクセスを無効にできます。この動作は、/etc/securetty ファイルのエントリーで管理されます。以下に例を示します。

  resource_registry:
    OS::TripleO::Services::Securetty: ../puppet/services/securetty.yaml

  parameter_defaults:
    TtyValues:
      - console
      - tty1
      - tty2
      - tty3
      - tty4
      - tty5
      - tty6

8.13. Identity サービスの CADF 監査

詳細な監査プロセスは、OpenStack デプロイメントの現在の状態を確認するのに役立ちます。これは、セキュリティーモデルにおけるそのロールにより、特に keystone で重要です。

Red Hat OpenStack Platform では、Identity およびトークン操作の CADF イベントを生成する keystone サービスにより、監査イベントのデータ形式として Cloud Auditing Data Federation (CADF) が採用されています。KeystoneNotificationFormat を使用して、keystone の CADF 監査を有効にできます。

  parameter_defaults:
    KeystoneNotificationFormat: cadf

8.14. login.defs 値の確認

新規システムユーザー (keystone 以外) のパスワード要件を強化するために、以下のこれらのパラメーターの例に従って、director はエントリーを /etc/login.defs に追加できます。

  resource_registry:
    OS::TripleO::Services::LoginDefs: ../puppet/services/login-defs.yaml

  parameter_defaults:
    PasswordMaxDays: 60
    PasswordMinDays: 1
    PasswordMinLen: 5
    PasswordWarnAge: 7
    FailDelay: 4

第9章 Dashboard サービスの強化

Dashboard サービス (horizon) は、管理者が設定した制限内で独自のリソースをプロビジョニングするためのセルフサービスポータルをユーザーに提供します。OpenStack API と同じ機密性で Dashboard サービスのセキュリティーを管理します。

9.1. Dashboard サービスのデバッグ

DEBUG パラメーターのデフォルト値は False です。実稼働環境では、デフォルト値を保持してください。この設定は、調査中のみ変更してください。DEBUG パラメーターの値を True に変更すると、Django は Web サーバーの状態に関する機密情報を含むスタックトレースをブラウザーユーザーに出力できます。

DEBUG パラメーターの値が True の場合は、ALLOWED_HOSTS 設定も無効になります。ALLOWED_HOSTS の設定の詳細については、ALLOWED_HOSTS の設定 を参照してください。

9.2. ドメイン名の選択

Dashboard サービス (horizon) は、任意のレベルの共有ドメインではなく、2 次レベルのドメインにデプロイすることを推奨します。それぞれの例を以下に示します。

  • 2 次レベルのドメイン: https://example.com
  • 共有サブドメイン: https://example.public-url.com

Dashboard サービスを専用の 2 次レベルのドメインにデプロイすると、ブラウザーの same-origin ポリシーに基づいて、Cookie とセキュリティートークンが他のドメインから分離されます。サブドメインにデプロイされた場合、ダッシュボードサービスのセキュリティーは、同じ 2 次レベルのドメインにデプロイされた最も安全性の低いアプリケーションと同等になります。

クッキーでサポートされるセッションストアを回避し、HTTP Strict Transport Security (HSTS) (本書で説明されている) を設定することにより、このリスクをさらに軽減できます。

注記

https://example/ などのベアドメインへの Dashboard サービスのデプロイはサポートされていません。

9.3. ALLOWED_HOSTS の設定

Horizon は python Django ウェブフレームワークでビルドされており、誤解を招く HTTP Host ヘッダーに関連するセキュリティ脅威からの保護が必要です。この保護を適用するには、OpenStack ダッシュボードによって提供される FQDN を使用するように ALLOWED_HOSTS を設定します。

ALLOWED_HOSTS 設定を設定すると、このリストの値と一致しない Host ヘッダーを持つ HTTP 要求は拒否され、エラーが発生します。

手順

  1. テンプレートの parameter_defaults の下で、HorizonAllowedHosts パラメーターの値を設定します。

    parameter_defaults:
        HorizonAllowedHosts: <value>

    <value> を OpenStack ダッシュボードによって提供される FQDN に置き換えます。

  2. 変更したテンプレートを使用してオーバークラウドをデプロイし、環境に必要な他のすべてのテンプレートをデプロイします。

9.4. クロスサイトスクリプティング (XSS)

OpenStack ダッシュボードは、ほとんどのフィールドで Unicode 文字セット全体を受け入れます。悪意のある攻撃者は、この拡張性を利用して、クロスサイトスクリプティング (XSS) の脆弱性をテストしようとする可能性があります。OpenStack Dashboard サービス (horizon) には、XSS の脆弱性を強化するツールがあります。カスタムダッシュボードでこれらのツールを正しく使用することが重要です。カスタムダッシュボードに対して監査を実行する場合は、次の点に注意してください。

  • mark_safe 関数
  • is_safe: カスタムテンプレートタグと共に使用する場合
  • safe テンプレートタグ
  • 自動エスケープがオフで、不適切にエスケープされたデータを評価する可能性のある JavaScript の場合

9.5. クロスサイトリクエストフォージェリー (CSRF)

複数の JavaScript インスタンスを使用する Dashboard は、@csrf_exempt デコレーターの不適切な使用など、脆弱性について監査する必要があります。CORS (Cross Origin Resource Sharing) の制限を下げる前に、推奨されるセキュリティー設定に従っていないダッシュボードを評価してください。各応答で制限付き CORS ヘッダーを送信するように Web サーバーを設定します。ダッシュボードのドメインとプロトコルのみを許可します (例: Access-Control-Allow-Origin: https://example.com/)。ワイルドカードオリジンを許可しないでください。

9.6. iframe 埋め込みの許可

DISALLOW_IFRAME_EMBED 設定は、Dashboard が iframe 内に埋め込まれるのを防ぎます。従来のブラウザーは、クロスフレームスクリプティング (XFS) に対して脆弱性があります。したがって、このオプションを使用すると、iframes を要求しないデプロイメントにさらにセキュリティー強化機能が追加されます。この設定は、デフォルトで True に設定されていますが、必要な場合は環境ファイルを使用して無効にできます。

手順

  • 以下のパラメーターを使用して、iframe 埋め込みを許可できます。
    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false
注記

これらの設定は、潜在的なセキュリティーの影響を完全に理解した後にのみ、False に設定するべきです。

9.7. Dashboard トラフィックの HTTPS 暗号化の使用

HTTPS を使用して Dashboard トラフィックを暗号化することが推奨されます。これは、認識されている認証局 (CA) からの有効な信頼される証明書を使用するように設定することで実行できます。プライベート組織が発行した証明書は、信頼の root がすべてのユーザーブラウザーで事前インストールされている場合にのみ適切になります。

完全修飾 HTTPS URL にリダイレクトするように、Dashboard ドメインへの HTTP 要求を設定します。

詳細は、Ansible を使用した TLS-e の実装を参照してください。

9.8. HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security(HSTS) は、最初にセキュアな接続を行った後に、ブラウザーが後続の非セキュアな接続を確立できないようにします。パブリックまたは信頼できないゾーンに HTTP サービスをデプロイした場合、HSTS が特に重要になります。

director ベースのデプロイメントの場合、この設定は /usr/share/openstack-tripleo-heat-templates/deployment/horizon/horizon-container-puppet.yaml ファイルでデフォルトで有効になっています。

horizon::enable_secure_proxy_ssl_header: true

検証

オーバークラウドがデプロイされたら、検証のために Red Hat OpenStack ダッシュボード (horizon) の local_settings ファイルを確認します。

  1. ssh を使用してコントローラーに接続します。

    $ ssh heat-admin@controller-0
  2. SECURE_PROXY_SSL_HEADER パラメーターの値が ('HTTP_X_FORWARDED_PROTO'、'https') であることを確認します。

    sudo egrep ^SECURE_PROXY_SSL_HEADER /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings
    SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

9.9. フロントエンドキャッシング

OpenStack API 要求から直接生成される動的コンテンツをレンダリングするため、Dashboard でフロントエンドキャッシュツールを使用することは推奨されません。そのため、varnish などのフロントエンドキャッシュレイヤーにより正しいコンテンツが表示されなくなります。Dashboard は Django を使用します。これは Web サービスから直接提供される静的メディアに対応し、Web ホストのキャッシュの利点をすでに活用します。

9.10. セッションバックエンド

director ベースのデプロイメントの場合、horizon のデフォルトのセッションバックエンドは django.contrib.sessions.backends.cache で、memcached と組み合わされます。パフォーマンス上の理由から、このアプローチはローカルメモリーキャッシュに対して推奨されます。高可用性や負荷分散のインストールの場合により安全であり、単一キャッシュとして扱いながら複数のサーバーでキャッシュを共有することができます。

これらの設定は、director の horizon.yaml ファイルで確認することができます。

          horizon::cache_backend: django.core.cache.backends.memcached.MemcachedCache
          horizon::django_session_engine: 'django.contrib.sessions.backends.cache'

9.11. シークレットキーの確認

Dashboard は、一部のセキュリティー機能について共有の SECRET_KEY 設定に依存します。秘密鍵は、少なくとも 64 文字の長さで無作為に生成される文字列である必要があります。これは、すべてのアクティブな Dashboard インスタンスで共有する必要があります。この鍵を危険にさらすと、リモートの攻撃者は任意コードを実行できる可能性があります。このキーをローテーションすると、既存のユーザーセッションおよびキャッシュが無効になります。このキーをパブリックリポジトリーにコミットしないでください。

director のデプロイメントでは、この設定は HorizonSecret の値として管理されます。

9.12. セッションクッキーの設定

Dashboard セッションクッキーは、JavaScript などのブラウザーテクノロジーによる対話のために開くことができます。TLS everywhere を使用した director デプロイメントの場合、HorizonSecureCookies 設定を使用してこの動作を強化することができます。

注記

CSRF またはセッションクッキーを、先頭のドットでワイルドカードドメインを使用するように設定しないでください。

9.13. 静的メディア

Dashboard の静的メディアは、Dashboard ドメインのサブドメインにデプロイして、Web サーバーによって提供されます。また、外部のコンテンツ配信ネットワーク (CDN) の使用も受け入れ可能です。このサブドメインに Cookie を設定したり、ユーザーによって提供されるコンテンツを提供したりしないでください。メディアは HTTPS で提供される必要もあります。

Dashboard のデフォルト設定では、django_compressor を使用して CSS および JavaScript コンテンツを圧縮および最小化してから提供します。このプロセスは、デフォルトのリクエスト内動的圧縮を使用し、デプロイされたコードと共に得られたファイルをコピーまたは CDN サーバーに送付するのではなく、Dashboard をデプロイする前に静的に行う必要があります。圧縮は実稼働以外のビルド環境で実行する必要があります。これができない場合は、リソース圧縮を完全に無効にすることを検討してください。オンライン圧縮の依存関係 (less, Node.js) は、実稼働マシンにインストールしないでください。

9.14. パスワードの複雑性の検証

OpenStack Dashboard (horizon) は、パスワード検証チェックを使用してパスワードの複雑さを強制的に適用することができます。

パスワードの検証に正規表現を指定することや、テストに失敗した場合に表示されるヘルプテキストを指定することができます。以下の例では、8 文字から 18 文字までのパスワードを作成することをユーザーに要求します。

    parameter_defaults:
      HorizonPasswordValidator: '^.{8,18}$'
      HorizonPasswordValidatorHelp: 'Password must be between 8 and 18 characters.'

この変更をデプロイメントに適用するには、設定を horizon_password.yaml という名前のファイルで保存し、以下のように overcloud deploy コマンドに渡します。<full environment> は、元のデプロイメントパラメーターをすべて含める必要があることを示します。以下に例を示します。

    openstack overcloud deploy --templates \
      -e <full environment> -e  horizon_password.yaml

9.15. 管理者パスワードチェックの強制

以下の設定は、デフォルトで True に設定されていますが、必要な場合は環境ファイルを使用して無効にできます。

注記

これらの設定は、潜在的なセキュリティーの影響を完全に理解した後にのみ、False に設定するべきです。

Dashboard の local_settings.py ファイルの ENFORCE_PASSWORD_CHECK 設定により、Change Password フォームに Admin Password フィールドが表示されます。これは、管理者がパスワード変更を開始していることを検証するのに役立ちます。

環境ファイルを使用して ENFORCE_PASSWORD_CHECK を無効にすることができます。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::enforce_password_check: false

9.16. パスワード表示の無効化

以下の設定は、デフォルトで True に設定されていますが、必要な場合は環境ファイルを使用して無効にできます。

注記

これらの設定は、潜在的なセキュリティーの影響を完全に理解した後にのみ、False に設定するべきです。

パスワード表示ボタンは、ダッシュボードのユーザーが入力するパスワードを表示できるようにします。このオプションは、DISABLE_PASSWORD_REVEAL パラメーターを使用して切り替えることができます。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disable_password_reveal: false

9.17. ダッシュボードのログオンバナーの表示

HIPAA、PCI-DSS、および米国政府などの規制では、ユーザーログオンバナーを表示する必要があります。Red Hat OpenStack Platform (RHOSP) Dashboard (horizon) では、horizon コンテナー内に保管されるデフォルトのテーマ (RCUE) が使用されます。

カスタムの Dashboard コンテナーでは、/usr/share/openstack-dashboard/openstack_dashboard/themes/rcue/templates/auth/login.html ファイルを手動で編集して、ログオンバナーを作成できます。

手順

  1. {% include 'auth/_login.html' %} セクションの直前に、必要なログオンバナーを入力します。HTML タグが許可されます。

    <snip>
    <div class="container">
      <div class="row-fluid">
        <div class="span12">
          <div id="brand">
            <img src="../../static/themes/rcue/images/RHOSP-Login-Logo.svg">
          </div><!--/#brand-->
        </div><!--/.span*-->
    
        <!-- Start of Logon Banner -->
        <p>Authentication to this information system reflects acceptance of user monitoring agreement.</p>
        <!-- End of Logon Banner -->
    
        {% include 'auth/_login.html' %}
      </div><!--/.row-fluid→
    </div><!--/.container-->
    
    {% block js %}
      {% include "horizon/_scripts.html" %}
    {% endblock %}
    
      </body>
    </html>

上の例では、次のようなダッシュボードが作成されます。

logonbanner

9.18. ファイルのアップロードサイズの制限

オプションとして、ファイルのアップロードのサイズを制限するように Dashboard を設定できます。この設定は、さまざまなセキュリティー強化ポリシーで必要になる場合があります。

LimitRequestBody: この値 (バイト単位) は、Dashboard を使用して転送できるファイル (イメージや他の大きなファイルなど) の最大サイズを制限します。

重要

この設定は、Red Hat では正式にテストされていません。この設定の影響を十分にテストしてから、実稼働環境にデプロイすることが推奨されます。

注記

値が小さすぎると、ファイルのアップロードは失敗します。

たとえば、この設定では、各アップロードファイルが最大 10 GB (10737418240) に制限されます。実際のデプロイメントに合わせて、この値を修正する必要があります。

  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf/httpd.conf

    <Directory />
      LimitRequestBody 10737418240
    </Directory>
  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/10-horizon_vhost.conf

    <Directory "/var/www">
      LimitRequestBody 10737418240
    </Directory>
  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/15-horizon_ssl_vhost.conf

    <Directory "/var/www">
      LimitRequestBody 10737418240
    </Directory>
注記

これらの設定ファイルは Puppet によって管理されるため、openstack overcloud deploy プロセスを実行するたびに、マネージド外の変更が上書きされます。

第10章 Red Hat OpenStack Platform ネットワーキングサービス

OpenStack Networking サービス (neutron) により、エンドユーザーまたはプロジェクトがネットワークリソースを定義および消費できるようになります。OpenStack Networking は、ネットワーク設定のオーケストレーションに加えて、クラウド内のインスタンスのネットワーク接続や IP アドレスを定義するためのプロジェクト向け API を提供します。API 中心のネットワークサービスへの移行により、クラウドアーキテクトと管理者は、物理ネットワークおよび仮想ネットワークのインフラストラクチャーおよびサービスをセキュアにするための優れたプラクティスを考慮する必要があります。

OpenStack Networking は、オープンソースのコミュニティーまたはサードパーティーサービスを使用して API を拡張性を提供するプラグインアーキテクチャーと共に設計されました。アーキテクチャーの設計要件を評価する上で、OpenStack Networking のコアサービス、サードパーティー製品で提供される追加のサービス、物理インフラストラクチャーに実装する必要のある補助サービスを判断しておくことは重要です。

本項では、OpenStack Networking の実装時に、プロセスと適切なプラクティスについて概説します。

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

OpenStack Networking は、複数のノードに複数のプロセスをデプロイするスタンドアロンのサービスです。これらのプロセスは、相互、その他の OpenStack サービスと対話します。OpenStack Networking サービスの主なプロセスは、neutron-server で、OpenStack Networking API を公開し、追加の処理のためにプロジェクト要求をプラグインスイートに渡す Python デーモンです。

OpenStack Networking のコンポーネントは以下のとおりです。

  • Neutron サーバー (neutron-server および neutron-*-plugin): neutron-server サービスは、Networking API とその拡張機能 (またはプラグイン) と対話するためにコントローラーノード上で実行されます。また、各ポートのネットワークモデルと IP アドレス処理も実施します。neutron-server では、永続データベースへの直接アクセスが必要です。エージェントは、neutron-server を介してデータベースに間接的にアクセスできます。このデータベースは AMQP (Advanced Message Queuing Protocol) を使用して通信します。
  • Neutron データベース: データベースは neutron 情報の一元化ソースで、API がデータベースのトランザクションをすべて記録します。これにより、複数の Neutron サーバーが同じデータベースクラスターを共有でき、すべてが同期され、ネットワーク設定トポロジーの永続性が可能になります。
  • プラグインエージェント (neutron-*-agent): 各コンピュートノードおよびネットワークノード (L3 および DHCP エージェントあり) で実行され、ローカルの仮想スイッチ (vswitch) 設定を管理します。有効なプラグインは有効なエージェントを決定します。これらのサービスにはメッセージキューのアクセスが必要で、使用されているプラグインによっては、外部ネットワークコントローラーまたは SDN 実装へのアクセスが必要です。OpenDaylight (ODL) や Open Virtual Network (OVN) などの一部のプラグインでは、コンピュートノード上に python エージェントを必要としません。統合には、有効な Neutron プラグインのみが必要です。
  • DHCP エージェント (neutron-dhcp-agent): プロジェクトネットワークへの DHCP サービスを提供します。このエージェントはすべてのプラグインで同じで、DHCP 設定を維持します。neutron-dhcp-agent にはメッセージキューのアクセスが必要です。プラグインに応じてオプションになります。
  • メタデータエージェント (neutron-metadata-agentneutron-ns-metadata-proxy): インスタンスオペレーティングシステムの設定とユーザー指定の初期スクリプト ('userdata') を適用するために使用されるメタデータサービスを提供します。この実装では、cloud-init が送信するメタデータ API 要求をメタデータエージェントにプロキシー化するために、L3 または DHCP エージェント名前空間で neutron-ns-metadata-proxy を実行する必要があります。
  • L3 エージェント (neutron-l3-agent): プロジェクトネットワーク上の仮想マシンの外部ネットワークアクセスに L3/NAT 転送します。メッセージキューのアクセスが必要です。プラグインに応じてオプションになります。
  • ネットワークプロバイダーサービス (SDN サーバー/サービス): プロジェクトネットワークに対して追加のネットワークサービスを提供します。これらの SDN サービスは、REST API などの通信チャネルを介して neutron-server、neutron-plugin、およびプラグインエージェントと対話する可能性があります。

以下の図は、OpenStack Networking コンポーネントのアーキテクチャーおよびネットワークフローの図を示しています。

ネットワーク接続

このアプローチは、分散仮想ルーター (DVR) および Layer-3 高可用性 (L3HA) が使用された場合に大幅に変更されることに注意してください。L3HA はルーター間で VRRP を実装するため、これらのモードは neutron のセキュリティーランドスケープを変更します。デプロイメントは、ルーターに対する DoS 攻撃を軽減できるように適切にサイズで強化する必要があります。また、VRRP スプーフィングの脅威に対処するために、ルーター間のローカルネットワークトラフィックを機密として扱う必要があります。DVR はネットワークコンポーネント (ルーティングなど) をコンピュートノードに移行する一方で、まだネットワークノードが必要です。したがって、コンピュートノードはパブリックネットワーク間のアクセスを必要とするため、ファイアウォールルールとセキュリティーモデルがこのアプローチをサポートする必要があるため、公開機能が高まり、お客様が追加でセキュリティーを考慮する必要があります。

10.2. 物理サーバーでの Neutron サービスの配置

本項では、コントローラーノード、ネットワークノード、および実行中のインスタンス用のコンピュートノードセットが含まれる標準のアーキテクチャーを説明します。物理サーバーのネットワーク接続を確立するために、通常の neutron デプロイメントは、4 つの異なる物理データセンターネットワークで設定されます。

ネットワークドメインの図
  • 管理ネットワーク: OpenStack コンポーネント間の内部通信に使用されます。このネットワークの IP アドレスはデータセンター内でのみ到達でき、管理セキュリティーゾーンとみなされます。デフォルトでは、Management network ロールは Internal API ネットワークにより実行されます。
  • ゲストネットワーク: ゲストクラウドデプロイメント内の仮想マシンデータ通信に使用します。このネットワークの IP アドレス要件は、使用中の OpenStack Networking プラグインや、プロジェクトによる仮想ネットワークの選択肢により異なります。このネットワークは、ゲストセキュリティーゾーンとみなされます。
  • 外部ネットワーク: 一部のデプロイメントシナリオにおいて、インターネットにアクセスできる仮想マシンを提供するのに使用します。このネットワークの IP アドレスは、インターネット上の誰でも到達できるはずです。このネットワークは、パブリックセキュリティーゾーンにあると見なされます。このネットワークは、neutron 外部ネットワーク により提供されます。これらの neutron VLAN は、外部ブリッジ上でホストされます。これらは Red Hat OpenStack Platform director により作成されませんが、デプロイ後の neutron により作成されます。
  • パブリック API ネットワーク: OpenStack Networking API を含むすべての OpenStack API をプロジェクトに公開する。このネットワークの IP アドレスは、インターネット上の誰でも到達できるはずです。これは、IP ブロック内の IP アドレスの完全な範囲より小さい IP 割り当て範囲を使用する外部ネットワークのサブネットを作成することができるので、外部ネットワークと同じネットワークである可能性があります。このネットワークは、パブリックセキュリティーゾーンにあると見なされます。

このトラフィックを別のゾーンに分割することを推奨します。詳細は次のセクションを参照してください。

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

重大なシステムは互いに分離させて、セキュリティーゾーンという概念を使用することを推奨します。実用的な方法では、VLAN およびファイアウォールルールを使用してネットワークトラフィックを分離します。このキュレートは細かい詳細で行い、neutron に接続する必要のあるサービスのみがこれを実行できるようにする必要があります。

以下の図は、ゾーンが特定のコンポーネントを分離するために作成されていることがわかります。

  • ダッシュボード: パブリックネットワークおよび管理ネットワークへのアクセス。
  • keystone: 管理ネットワークへのアクセスが可能です。
  • コンピュートノード: 管理用ネットワークおよびコンピュートインスタンスにアクセスできます。
  • ネットワークノード: 使用中の neutron-plugin に応じて、管理ネットワーク、コンピュートインスタンス、およびパブリックネットワークへのアクセスが可能です。
  • SDN サービスノード: 製品の使用および設定に応じて、管理サービス、コンピュートインスタンス、および公開されている。
ネットワークゾーン

10.4. ネットワークサービス

OpenStack Network インフラストラクチャーを設計するための初期アーキテクチャーフェーズでは、適切なセキュリティー制御および監査のメカニズムを特定できるようにするためにも、適切な専門知識で物理ネットワークインフラストラクチャーのデザインをアシストできるようにしておくことが重要です。

OpenStack Networking は、プロジェクト固有の仮想ネットワークをアーキテクトする機能を提供する、仮想ネットワークサービスのレイヤーを追加します。現在、これらの仮想化サービスは、従来のネットワークに対応するネットワークほど成熟していません。このような仮想化サービスの現在の状態を、仮想化および従来のネットワーク境界に実装する必要のあるコントロールを定めるため、それらを採用する前にこれらの仮想化サービスの現在の状態を考慮してください。

10.5. VLAN およびトンネリングを使用した L2 分離

OpenStack Networking は、プロジェクト/ネットワークの組み合わせ: VLAN (IEEE 802.1Q タグ付け) または VXLAN または GRE カプセル化を使用する L2 トンネルのトラフィック分離に、2 つの異なるメカニズムを使用できます。OpenStack デプロイメントのスコープおよびスケーリングは、トラフィックの分離または分離に使用する方法を決定します。

VLAN

VLAN は、特定の VLAN ID (VID) フィールド値を持つ IEEE 802.1Q ヘッダーが含まれる特定の物理ネットワーク上のパケットとして認識されます。同じ物理ネットワークを共有する VLAN ネットワークは、L2 で相互に分離され、IP アドレス空間が重複している可能性もあります。VLAN ネットワークをサポートする各物理ネットワークは、別個の VLAN トランク k として扱われ、異なる領域の VID 値を持ちます。有効な VID の値は 1 から 4094 までです。

VLAN 設定は、OpenStack の設計要件によって異なります。OpenStack Networking が VLAN をより効率的に使用できるようにするには、VLAN 範囲 (各プロジェクトの 1 つ) を割り当てて、各コンピュートノードの物理スイッチポートを VLAN トランクポートに切り替える必要があります。

トンネリング

ネットワークトンネリングは、各プロジェクト/ネットワークの組み合わせを、その組み合わせに属するネットワークトラフィックの特定に使用される一意の tunnel-id と組み合わせてカプセル化します。プロジェクトの L2 ネットワーク接続は、物理ローリティーまたは下層のネットワーク設計とは独立しています。IP パケット内にトラフィックをカプセル化することで、そのトラフィックはレイヤー 3 の境界をまたがり、事前設定済みの VLAN および VLAN トランク接続の必要性がなくなります。トンネリングにより、ネットワークデータのトラフィックに難読化のレイヤーが追加され、個別のプロジェクトトラフィックの可視性が、ビューのモニターポイントを模倣します。

OpenStack Networking は現在 GRE および VXLAN カプセル化の両方をサポートしています。L2 分離を提供する技術は、デプロイメントで作成されるプロジェクトネットワークのスコープおよびサイズによって異なります。

10.6. アクセス制御リスト

Compute は、OpenStack Networking サービスの使用により、プロジェクトのネットワークトラフィックのアクセス制御をサポートします。セキュリティーグループにより、管理者およびプロジェクトがトラフィックの種別を指定することができ、かつ方向 (ingress/egress) が仮想インターフェイスポートを通過できる方向 (ingress/egress) を指定することができます。セキュリティーグループルールは、ステートフル L2-L4 トラフィックフィルターです。

10.7. L3 ルーティングおよび NAT

OpenStack Networking ルーターは、複数の L2 ネットワークを接続でき、1 つ以上のプライベート L2 ネットワークを、インターネットにアクセスするためのパブリックネットワークなど、共有外部ネットワークに接続するゲートウェイを提供することもできます。

L3 ルーターは、ルーターを外部ネットワークにリンクするゲートウェイポートで、基本的なネットワークアドレス変換 (SNAT および DNAT) 機能を提供します。このルーター SNAT (ソース NAT) デフォルトですべての egress トラフィックをサポートし、Floating IP をサポートします。Floating IP は、外部ネットワーク上のパブリック IP からルーターに接続された他のサブネットにプライベート IP に静的 1 対 1 のプライベート IP へのマッピングを作成します。Floating IP (DNAT 経由) は、インスタンスに外部インバウンドの接続性を提供し、あるインスタンスから別のインスタンスから移行することができます。

プロジェクトインスタンスのより詳細な接続のために、プロジェクトごとの L3 ルーティングと Floating IP を使用することを検討してください。パブリックネットワークに接続されたインスタンス、または Floating IP を使用して、特別な考慮する必要があります。外部で公開される必要があるサービスのみに対して、セキュリティーグループの使用を慎重に検討することが推奨されます。

10.8. QoS (Quality of Service)

デフォルトでは、QoS (Quality of Service) ポリシーおよびルールはクラウド管理者によって管理されます。これにより、プロジェクトが特定の QoS ルールを作成できず、またポートに特定のポリシーをアタッチすることはできません。管理者が通信するアプリケーションなどの一部のユースケースでは、管理者がプロジェクトを信頼し、独自のポリシーをポートに作成および接続できるようにします。そのためには、policy.json ファイルを変更します。

Red Hat OpenStack Platform 12 から、neutron は、受信トラフィックと送信トラフィックの両方で、帯域幅を制限する QoS ルールをサポートしています。この QoS ルールは QosBandwidthLimitRule という名前で、毎秒キロビットで測定される負の整数を 2 つ受け取ります。

  • max-kbps: 帯域幅
  • max-burst-kbps: バーストバッファー

QoSBandwidthLimitRule は、neutron Open vSwitch、Linux ブリッジ、および SR-IOV ドライバーに実装されています。ただし、SR-IOV ドライバーでは、max-burst-kbps の値が使用されず、設定されている場合は無視されます。

QoS ルール QosDscpMarkingRule は、IPv4 (RFC 2474) のサービスヘッダーのタイプに Differentiated Service Code Point (DSCP) 値を設定し、仮想マシンから出るすべてのトラフィックで、IPv6 のトラフィッククラスヘッダー (ルールが適用されます) を設定します。これは、ネットワークが輻輳に合致するように、パケットのドロップの優先度を示す、有効な値が 21 の 6 ビットヘッダーです。また、ファイアウォールで使用して、アクセス制御リストに対する有効なトラフィックまたは無効なトラフィックを一致させることもできます。

10.9. ロードバランシング

OpenStack Load-balancing サービス (octavia) は、Red Hat OpenStack Platform director のインストール環境で、Load Balancing-as-a-Service (LBaaS) の実装を提供します。負荷分散機能を実現するために、octavia では複数のプロバイダードライバーを有効にする設定がサポートされます。参照プロバイダードライバー (Amphora プロバイダードライバー) は、オープンソースのスケーラビリティーに優れた高可用性負荷分散プロバイダーです。仮想マシン群 (amphora と総称される) を管理し、オンデマンドで起動することで、負荷分散サービスを提供します。

Load-balancing サービスの詳細は、Using Octavia for Load Balancing-as-a-Service を参照してください。

10.10. Networking サービスのハードニング

本項では、OpenStack デプロイメント内のプロジェクトネットワークセキュリティーに適用される、OpenStack Networking の設定に関する適切なプラクティスについて説明します。

10.10.1. プロジェクトネットワークサービスのワークフロー

OpenStack Networking は、ユーザーがネットワークリソースのセルフサービス設定を提供します。クラウドアーキテクトとオペレーターは、ユーザーが利用可能なネットワークリソースを作成、更新、破棄できる設計のユースケースを評価することが重要です。

10.10.2. ネットワークリソースポリシーエンジン

OpenStack Networking 内のポリシーエンジンと設定ファイル (policy.json) は、プロジェクトネットワークのメソッドおよびオブジェクトに対するユーザーの詳細な認可を提供する方法を提供します。OpenStack Networking ポリシーの定義は、ネットワークの可用性、ネットワークセキュリティー、および OpenStack セキュリティー全体に影響します。クラウドアーキテクトとオペレーターは、ネットワークリソースの管理に対するユーザーおよびプロジェクトアクセスに対して、ポリシーを慎重に評価する必要があります。

注記

このポリシーはセキュリティーの問題に応じて変更できるため、デフォルトのネットワークリソースポリシーを確認することが重要です。

OpenStack が複数の外部アクセスポイントを提供する場合は、複数の仮想 NIC を複数の外部アクセスポイントにアタッチするプロジェクトの機能を制限することが重要です。よりこれらのセキュリティーゾーンがブリッジされ、セキュリティーへの不正アクセスの原因となる可能性があります。Compute が提供するホスト集約関数を使用するか、プロジェクトインスタンスを異なる仮想ネットワーク設定を持つ複数のプロジェクトに分割することで、このリスクを軽減することができます。ホストアグリゲートの詳細は、Creating and managing host aggregates を参照してください。

10.10.3. セキュリティーグループ

セキュリティーグループとは、セキュリティーグループルールのコレクションです。セキュリティーグループとそれらのグループにより、管理者およびプロジェクトがトラフィックの種別を指定することができ、かつ方向 (ingress/egress) が仮想インターフェイスポートを通過できる方向 (ingress/egress) を指定することができます。OpenStack Networking で仮想インターフェイスのポートが作成されると、セキュリティーグループが関連付けられます。デプロイメントごとに動作を変更するには、デフォルトのセキュリティーグループにルールを追加できます。

Compute API を使用してセキュリティーグループを変更する場合、更新されたセキュリティーグループはインスタンスのすべての仮想インターフェイスポートに適用されます。これは、neutron にあるように、コンピュートセキュリティーグループ API がポートベースではなくインスタンスベースであるためです。

10.10.4. ARP スプーフィングの緩和策

OpenStack Networking には、インスタンスの ARP スプーフィングの脅威を緩和するための組み込み機能が含まれています。これは、結果となるリスクに注意を払う場合を除き無効にしないでください。

10.10.5. 認証にセキュアプロトコルを使用

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で、[keystone_authtoken] セクションの auth_uri の値が https: で始まる Identity API エンドポイントに設定されていることを確認します。

第11章 Red Hat OpenStack Platform でのブロックストレージの強化

OpenStack Block Storage (cinder) は、ソフトウェア (サービスおよびライブラリー) を提供するサービスで、永続的なブロックレベルのストレージデバイスをセルフサービスで管理するサービスです。これにより、Compute (nova) インスタンスで使用する Block Storage リソースへのオンデマンドアクセスが作成されます。これにより、ブロックストレージのプールをさまざまなバックエンドストレージデバイスに仮想化することで、ソフトウェア定義のストレージが作成され、ソフトウェア実装または従来のハードウェアストレージ製品のいずれかになります。これの主な機能は、ブロックデバイスの作成、割り当て、切断を管理することです。コンシューマーは、バックエンドストレージ機器の種類や、そのタイプの配置先に関する知識は必要ありません。

コンピュートインスタンスは、iSCSI、ATA over Ethernet、または Fibre-Channel などの業界標準のストレージプロトコルを使用してブロックストレージを保存し、取得します。これらのリソースは、OpenStack ネイティブ HTTP RESTful API を使用して管理および設定されます。

11.1. 要求のボディーの最大サイズの設定

リクエストごとの最大ボディーサイズが定義されていない場合、攻撃者は大きなサイズの任意の OSAPI リクエストを作成します。すると、その結果サービスがクラッシュし、最終的にサービス拒否攻撃につながることになります。最大値を割り当てると、悪意のあるリクエストはすべてブロックされ、引き続きサービスの可用性が確保されます。

cinder.conf[oslo_middleware] セクションの max_request_body_size114688 に設定されているかどうかを確認します。

11.2. ボリュームの暗号化の有効化

暗号化されていないボリュームデータにより、攻撃者が多数の仮想マシンのデータを読み取ることができるため、ボリュームホスティングプラットフォームは特に攻撃者にとってハイバリューターゲットとなります。さらに、物理ストレージメディアは、盗まれたり、再マウントされたりする可能性ががあり、別のマシンからアクセスされることもあり得ます。ボリュームのデータとボリュームのバックアップを暗号化すると、これらのリスクを軽減し、ボリュームをホストしているプラットフォームに厚い防御を提供することができます。Block Storage (cinder) は、ディスクに書き込まれる前にボリュームデータを暗号化できるため、ボリュームの暗号化を有効にし、秘密鍵ストレージに Barbican を使用することを検討してください。

11.3. ボリュームの接続

ブロックストレージデバイスを消去する方法は複数あります。従来の方法として、lvm_type を thin に設定し、続いて volume_clear パラメーターを使用します。または、ボリュームの暗号化機能があれば、ボリュームの暗号化キーが削除される場合にボリュームのワイプは必要ありません。

注記

以前のバージョンでは、lvm_type=default は wipe を示すために使用されていました。この手法は依然として機能しますが、secure delete の設定に lvm_type=default は推奨されません。

volume_clear パラメーターは、zero または shred のいずれかを引数として受け入れることができます。zero は、デバイスにゼロのパスを 1 つ書き込みます。shred 操作は、事前に決定したビットパターンの 3 つを書き込みます。

第12章 Shared File Systems (Manila) のセキュリティー強化

Shared File Systems サービス (manila) は、マルチプロジェクトのクラウド環境で共有ファイルシステムを管理するためのサービスセットを提供します。manila を使用すると、共有ファイルシステムを作成し、可視性、アクセシビリティー、クォータなどの属性を管理できます。

manila についての詳しい情報は、Storage Guide(https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.2/html-single/storage_guide/) を参照してください。

12.1. manila のセキュリティーに関する考慮事項

Manila は keystone に登録されており、manila endpoints コマンドを使用して API を特定することができます。以下に例を示します。

 $ manila endpoints
 +-------------+-----------------------------------------+
 | manila      | Value                                   |
 +-------------+-----------------------------------------+
 | adminURL    | http://172.18.198.55:8786/v1/20787a7b...|
 | region      | RegionOne                               |
 | publicURL   | http://172.18.198.55:8786/v1/20787a7b...|
 | internalURL | http://172.18.198.55:8786/v1/20787a7b...|
 | id          | 82cc5535aa444632b64585f138cb9b61        |
 +-------------+-----------------------------------------+

 +-------------+-----------------------------------------+
 | manilav2    | Value                                   |
 +-------------+-----------------------------------------+
 | adminURL    | http://172.18.198.55:8786/v2/20787a7b...|
 | region      | RegionOne                               |
 | publicURL   | http://172.18.198.55:8786/v2/20787a7b...|
 | internalURL | http://172.18.198.55:8786/v2/20787a7b...|
 | id          | 2e8591bfcac4405fa7e5dc3fd61a2b85        |
 +-------------+-----------------------------------------+

デフォルトでは、manila API サービスは、tcp6 のポート 8786 でのみリッスンします。これは、IPv4 と IPv6 の両方をサポートします。

manila は複数の設定ファイルを使用します。これらは /var/lib/config-data/puppet-generated/manila/ に保存されます。

 api-paste.ini
 manila.conf
 policy.json
 rootwrap.conf
 rootwrap.d

 ./rootwrap.d:
 share.filters

manila を root 以外のサービスアカウントで実行するように設定し、システム管理者のみが変更できるようにファイルのパーミッションを変更することを推奨します。manila では、管理者のみが設定ファイルに書き込みを行うことができ、サービスは manila グループのグループメンバーシップを介して読み取りのみを行うことを想定します。サービスアカウントパスワードが含まれるため、他のユーザーがこれらのファイルを読み取り可能であってはいけません。

注記

root ユーザーのみが、rootwrap.confmanila-rootwrap の設定および rootwrap.d/share.filters の共有ノードの manila-rootwrap コマンドフィルターに書き込みできる必要があります。

12.2. manila のネットワークおよびセキュリティーモデル

manila の共有ドライバーは、共有操作を管理するためにバックエンドに設定可能な Python クラスです。これらの一部はベンダー固有のものになります。バックエンドは、manila-share サービスのインスタンスです。manila は、多くの異なるストレージシステム用の共有ドライバーを持ち、商用ベンダーおよびオープンソースソリューションの両方をサポートします。各共有ドライバーは、1 つまたは複数のバックエンドモード (共有用サーバー および 共有用サーバーなし) をサポートします。管理者は、driver_handles_share_servers を使用して manila.conf でモードを指定して選択します。

共有サーバーは、共有ファイルシステムをエクスポートする論理 Network Attached Storage (NAS) サーバーです。今日のバックエンドストレージシステムは高機能で、異なる OpenStack プロジェクト間でデータパスとネットワークパスを分離することができます。

manila 共有ドライバーによってプロビジョニングされる共有サーバーは、作成するプロジェクトユーザーに属する分離ネットワーク上に作成されます。共有用サーバー モードは、ネットワークプロバイダーに応じて、フラットネットワークまたはセグメント化されたネットワークのいずれかで設定できます。

異なるモードのそれぞれのドライバーが、同じハードウェアを使用することができます。選択したモードによっては、設定ファイルでより多くの設定情報を提供する必要がある場合があります。

12.3. ファイル共有バックエンドモード

各共有ドライバーは、少なくとも 1 つの利用可能なドライバーモードをサポートします。

  • 共有用サーバー (driver_handles_share_servers = True): 共有ドライバーは共有サーバーを作成し、共有サーバーのライフサイクルを管理します。
  • 共有用サーバーなし (driver_handles_share_servers = False): ファイル共有サーバーの存在に依存するのではなく、管理者 (共有ドライバーではなく) がネットワークインターフェイスでベアメタルストレージを管理します。

共有用サーバーなしモード: このモードでは、ドライバーは共有サーバーを設定しないため、新しいネットワークインターフェイスを設定する必要はありません。ドライバーが管理するストレージコントローラーには必要なネットワークインターフェイスがすべて含まれていることを前提とします。ドライバーは、以前共有サーバーを作成せずに直接共有を作成します。このモードで稼働するドライバーを使用してファイル共有を作成するには、manila では、いずれかのプライベート共有ネットワークを作成する必要はありません。

注記

共有用サーバーなしモード では、manila は、ファイル共有をエクスポートするネットワークインターフェイスがすべてのプロジェクトからすでに到達可能であることを想定します。

共有用サーバーなし モードでは、共有ドライバーは共有サーバーのライフサイクルを処理しません。管理者は、プロジェクトの分離を提供するのに必要なストレージ、ネットワーク、およびその他のホスト側の設定を処理することが想定されます。このモードでは、管理者はファイル共有をエクスポートするホストとしてストレージを設定できます。OpenStack クラウド内のすべてのプロジェクトは、共通のネットワークパイプを共有します。分離がない場合、セキュリティーおよび QoS (Quality of Service) に影響を及ぼす可能性があります。共有用サーバーを処理しない共有ドライバーを使用する場合には、クラウドユーザーは、ファイルシステムの最上位ディレクトリー上のツリーウォークにより、信頼できないユーザーが自分のファイル共有にアクセスできないことを確認することはできません。パブリッククラウドでは、1 つのクライアントですべてのネットワーク帯域幅が使用される可能性があるため、管理者はそうならないように注意する必要があります。ネットワークのバランシングは、必ずしも OpenStack ツールだけを使用しなければならない訳ではなく、どの方法ででも実行できます。

共有用サーバーモード: このモードでは、ドライバーは共有用サーバーを作成して、既存の OpenStack ネットワークにプラグインすることができます。manila は、新規共有用サーバーが必要であるかどうかを判別し、共有ドライバーが必須共有用サーバーを作成するのに必要なすべてのネットワーク情報を提供します。

共有用サーバーを処理するドライバーモードでファイル共有を作成する場合、ユーザーはファイル共有をエクスポートすることを期待する共有ネットワークを提供する必要があります。manila は、このネットワークを使用して、このネットワーク上の共有用サーバーのネットワークポートを作成します。

共有用サーバー および 共有用サーバーなし バックエンドモードの両方で、セキュリティーサービス を設定することができます。ただし、共有用サーバーなし バックエンドモードでは、管理者はホストで必要な認証サービスを手動で設定する必要があります。共有用サーバー モードでは、manila は、生成する共有用サーバーでユーザーが識別するセキュリティーサービスを設定することができます。

12.4. manila のネットワーク要件

manila は、flatGREVLANVXLAN など、さまざまなネットワーク種別と統合できます。

注記

manila はネットワーク情報をデータベースに格納するだけで、実際のネットワークはネットワークプロバイダーによって提供されます。Manila は、OpenStack Networking サービス (neutron) およびスタンドアロンの事前設定されたネットワークの使用をサポートしています。

共有用サーバー バックエンドモードでは、共有ドライバーにより、ファイル共有ネットワークごとに共有用サーバーを作成および管理します。このモードは、2 つのバリエーションに分割できます。

  • 共有用サーバー バックエンドモードのフラットネットワーク
  • 共有用サーバー バックエンドモードのセグメント化されたネットワーク

ユーザーは、OpenStack Networking (neutron) サービスからのネットワークおよびサブネットを使用して、ファイル共有ネットワークを作成することができます。管理者が StandAloneNetworkPlugin の使用を決定した場合、ユーザーはネットワーク情報を提供する必要がありません。管理者が設定ファイルでこれを事前設定するためです。

注記

一部の共有ドライバーにより起動するファイル共有用サーバーは、Compute サービスで作成した Compute サーバーです。これらのドライバーの一部は、ネットワークプラグインに対応していません。

ファイル共有ネットワークが作成されると、manila はネットワークプロバイダーによって決定されたネットワーク情報 (ネットワーク種別、セグメンテーション ID (ネットワークがセグメンテーションを使用する場合)、およびネットワークの割り当て元の IP ブロック (CIDR 表記)) を取得します。

ユーザーは、AD、LDAP ドメイン、Kerberos レルムなどのセキュリティー要件を指定するセキュリティーサービスを作成できます。manila は、セキュリティーサービスで呼び出されるホストが、共有用サーバーが作成されるサブネットから到達可能であることを前提としています。これにより、このモードが使用されるケースが制限されます。

注記

共有ドライバーによっては、すべてのタイプのセグメンテーションに対応していない場合があります。詳細は、使用しているドライバーの仕様を参照してください。

12.5. manila を使用したセキュリティーサービス

manila は、ネットワーク認証プロトコルと統合することで、ファイル共有へのアクセスを制限できます。各プロジェクトには、クラウドの keystone 認証ドメインとは別に機能する独自の認証ドメインを持つことができます。このプロジェクトドメインを使用して、manila を含む OpenStack クラウド内で実行されるアプリケーションに承認 (AuthZ) サービスを提供することができます。利用可能な認証プロトコルには、LDAP、Kerberos、および Microsoft Active Directory 認証サービスが含まれます。

12.6. セキュリティーサービスの概要

ファイル共有を作成してエクスポート場所を取得した後、ユーザーにはファイル共有をマウントし、ファイルを操作するパーミッションがありません。ユーザーは、新規共有へのアクセスを明示的に取得する必要があります。

クライアントの認証および承認 (authN/authZ) は、セキュリティーサービスと共に実行できます。LDAP、Kerberos、または Microsoft Active Directory が共有ドライバーおよびバックエンドでサポートされている場合、manila はこれらを使用できます。

注記

場合によっては、NetApp, EMC などのセキュリティーサービスの 1 つを明示的に指定する必要があります。Windows ドライバーには、CIFS プロトコルを使用したファイル共有の作成に Active Directory が必要です。

12.7. セキュリティーサービスの管理

セキュリティーサービス は、Active Directory ドメインや Kerberos ドメインなど、特定の共有ファイルシステムプロトコルのセキュリティーゾーンを定義するオプションのセットを抽象化する manila エンティティーです。セキュリティーサービスには、manila が指定のドメインに参加させるサーバーを作成するために必要な全情報が含まれます。

ユーザーは、API を使用してセキュリティーサービスの作成、更新、表示、および削除を行うことができます。セキュリティーサービスは、以下の前提条件に基づいて設計されています。

  • プロジェクトが、セキュリティーサービスの詳細を提供する。
  • 管理者がセキュリティーサービスに対応する (このようなセキュリティーサービスのサーバー側を設定する)。
  • manila API 内で、security_serviceshare_networks に関連付けられる。
  • 共有ドライバーは、セキュリティーサービスのデータを使用して、新規に作成された共有用サーバーを設定する。

セキュリティーサービスの作成時に、以下のいずれかの認証サービスを選択できます。

  • LDAP: Lightweight Directory Access Protocol。IP ネットワークを通じて分散ディレクトリー情報サービスにアクセスし、維持するためのアプリケーションプロトコル。
  • Kerberos: セキュアでないネットワーク上で通信するノードが、安全な方法で互いに ID を証明できるように、チケットベースで機能するコンピューターネットワーク認証プロトコル
  • Active Directory: Windows ドメインネットワーク向けに Microsoft が開発したディレクトリーサービス。LDAP、Microsoft バージョンの Kerberos、および DNS を使用します。

manila では、以下のオプションを使用してセキュリティーサービスを設定することができます。

  • プロジェクトネットワーク内で使用される DNS IP アドレス
  • セキュリティーサービスの IP アドレスまたはホスト名
  • セキュリティーサービスのドメイン
  • プロジェクトが使用するユーザーまたはグループ名
  • ユーザー名を指定した場合は、ユーザーのパスワード

既存のセキュリティーサービスエンティティーには、ファイル共有ネットワークエンティティーを関連付けることができます。このエンティティーは、manila に、ファイル共有グループのセキュリティーおよびネットワーク設定を通知します。指定したファイル共有ネットワークに対するセキュリティーサービスのリストを確認し、ファイル共有ネットワークから関連付けを解除することもできます。

ファイル共有の所有者として、管理者およびユーザーは、IP アドレス、ユーザー、グループ、または TLS 証明書を使用した認証でアクセスルールを作成することにより、ファイル共有へのアクセスを管理できます。認証方法は、設定して使用する共有ドライバーやセキュリティーサービスによって異なります。その後、特定の認証サービスを使用するようにバックエンドを設定することができます。これにより、manila および keystone を使用せずにクライアントと機能することができます。

注記

さまざまな認証サービスが、さまざまな共有ドライバーによりサポートされます。さまざまなドライバーによりサポートされる機能に関する詳細は、https://docs.openstack.org/manila/latest/admin/share_back_ends_feature_support_mapping.html を参照してください。

あるドライバーが特定の認証サービスをサポートするからと言って、任意の共有ファイルシステムプロトコルで設定できるという訳ではありません。サポート対象の共有ファイルシステムプロトコルは、NFS、CEPHFS、CIFS、GlusterFS、および HDFS です。特定のドライバーおよびそのセキュリティーサービスの設定に関する情報は、ドライバーベンダーのドキュメントを参照してください。

一部のドライバーは、セキュリティーサービスをサポートしますが、上記のセキュリティーサービスをサポートしないドライバーもあります。たとえば、NFS または CIFS 共有ファイルシステムプロトコルを使用する汎用ドライバーは、IP アドレスによる認証方法のみをサポートします。

注記

ほとんどの場合、CIFS 共有ファイルシステムプロトコルをサポートするドライバーは、Active Directory を使用して、ユーザー認証でアクセスを管理するように設定できます。

  • GlusterFS プロトコルをサポートするドライバーは、TLS 証明書を使用する認証で使用できます。
  • IP アドレスを使用した NFS プロトコル認証をサポートするドライバーは、唯一のサポートされているオプションです。
  • HDFS 共有ファイルシステムプロトコルは、NFS アクセスを使用するので、IP アドレスを使用して認証するように設定することもできます。

実稼働環境用の manila デプロイメントの推奨設定は、CIFS 共有プロトコルを使用してファイル共有を作成し、それを Microsoft Active Directory ディレクトリーサービスに追加することです。この設定では、集中データベースと、Kerberos および LDAP アプローチを統合するサービスが提供されます。

12.8. ファイル共有へのアクセスの制御

ユーザーは、作成するファイル共有にアクセスできる特定のクライアントを指定できます。keystone サービスにより、個別ユーザーが作成したファイル共有は、作成したユーザーおよび同じプロジェクト内のユーザーだけに表示されます。Manila により、ユーザーはパブリックに表示されるファイル共有を作成することができます。所有者がアクセス権を付与した場合、これらのファイル共有は、他の OpenStack プロジェクトに属するユーザーのダッシュボードに表示されます。ネットワーク上でアクセス可能な場合、これらの共有をマウントできる場合もあります。

ファイル共有の作成時に、キー --public を使用して、他のプロジェクトに対してファイル共有をパブリックにし、ファイル共有のリストにその共有を表示し、詳細情報を表示します。

policy.json ファイルに従って、ファイル共有の所有者として、管理者およびユーザーは、アクセスルールを作成することにより、ファイル共有へのアクセスを管理できます。manila access-allowmanila access-deny、および manila access-list コマンドを使用すると、指定されたファイル共有へのアクセスを許可、拒否、およびリスト表示することができます。

注記

manila は、ストレージシステムのエンドツーエンド管理を提供しません。したがって、別途バックエンドシステムを承認されていないアクセスから保護する必要があります。その結果、アウトオブバンドアクセスを取得することでバックエンドストレージデバイスが侵害された場合、manila API が提供する保護は損なわれる可能性があります。

ファイル共有が作成されたままの状態では、それに関連付けられたデフォルトのアクセスルールとマウントパーミッションはありません。これは、使用中のエクスポートプロトコルのマウント設定で確認できます。たとえば、NFS コマンド exportfs またはストレージの /etc/exports ファイルがあり、各リモートファイル共有を制御し、アクセスできるホストを定義します。誰もファイル共有をマウントできない場合、これは空です。リモート CIFS サーバーでは、設定を表示する net conf list コマンドがあります。hosts deny パラメーターは、共有ドライバーにより 0.0.0.0/0 に設定する必要があります。これは、いずれのホストも、ファイル共有のマウントを拒されることを意味します。

manila を使用して、サポートされるファイル共有へのアクセスレベルのいずれかを指定して、ファイル共有へのアクセスを許可または拒否できます。

  • rw: 読み取りおよび書き込み (RW) アクセス。これはデフォルト値です。
  • ro: 読み取り専用 (RO) アクセス
注記

RO アクセスレベルは、パブリックなファイル共有で役立ちます。この場合、管理者が特定のエディターまたはコントリビューターに対して読み取りおよび書き込み (RW) アクセスを提供し、残りのユーザー (ビューアー) には読み取り専用 (RO) アクセスを提供します。

サポートされる認証方法のいずれかも指定する必要があります。

  • IP: インスタンスの認証に IP アドレスを使用します。IP アクセスは、適切に形成された IPv4 アドレスまたは IPv6 アドレスで指定可能なクライアント、または CIDR 表記で指定されるサブネットに提供できます。
  • cert: インスタンスの認証に TLS 証明書を使用します。TLS アイデンティティーを IDENTKEY として指定します。有効な値は、証明書の共通名 (CN) の 64 文字までの任意の文字列です。
  • user: 指定したユーザーまたはグループ名で認証します。有効な値は、特殊文字を含む 4 から 32 文字の長さの英数字の文字列です。
注記

サポートされる認証方法は、使用する共有ドライバー、セキュリティーサービス、および共有ファイルシステムプロトコルにより異なります。サポート対象の共有ファイルシステムプロトコルは、MapRFS、CEPHFS、NFS、CIFS、および HDFS です。サポートされるセキュリティーサービスは、LDAP、Kerberos プロトコル、または Microsoft Active Directory サービスです。

アクセスルール (ACL) がファイル共有に対して正しく設定されていることを確認するには、そのパーミッションをリスト表示できます。

注記

ファイル共有にセキュリティーサービスを選択する場合は、共有ドライバーが利用可能な認証方法を使用してアクセスルールを作成できるかどうかを考慮する必要があります。サポートされるセキュリティーサービスは、LDAP、Kerberos、および Microsoft Active Directory です。

12.9. 共有種別のアクセス制御

共有種別は、管理者の定義する サービスの種別 で、プロジェクトに表示される説明および 追加仕様 と呼ばれるプロジェクトに表示されないキー/値ペアのリストで設定されます。manila-scheduler は追加仕様を使用してスケジューリングの決定を行い、ドライバーはファイル共有の作成を制御します。

管理者は共有種別の作成や削除が可能で、さらに、共有種別に manila 内での意味を持たせる追加仕様を管理することもできます。プロジェクトでは共有種別をリスト表示でき、それらを使用して新規ファイル共有を作成することができます。共有種別は public および private として作成できます。これは共有種別の可視性のレベルで、他のプロジェクトがリストに共有種別を表示し、新規ファイル共有を作成するのに使用できるかどうかを定義するものです。

デフォルトでは、共有種別は public として作成されます。共有種別を作成する時に --is_public パラメーターを使用して False に設定し、共有種別をプライベートに設定します。これにより、他のプロジェクトがリストに共有種別を表示したり、それを使用して新たなファイル共有を作成するのを防ぐことができます。一方、public の共有種別は、クラウド内のすべてのプロジェクトで利用できます。

manila により、管理者はプロジェクトの private の共有種別へのアクセスを許可または拒否することができます。指定したプライベート共有種別のアクセスに関する情報を取得することもできます。

注記

追加仕様により、共有種別はユーザーがファイル共有を作成する前にバックエンドをフィルターまたは選択するのに役立つため、共有種別へのアクセスを使用すると、特定のバックエンドにクライアントを限定することができます。

たとえば、admin プロジェクトの管理者ユーザーは、my_type という名前のプライベート共有種別を作成し、これをリストで確認できます。以下のコンソールの例では、ログインとログアウトが省略され、現在ログインしているユーザーを示す環境変数が提供されます。

 $ env | grep OS_
 ...
 OS_USERNAME=admin
 OS_TENANT_NAME=admin
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs              | optional_extra_specs  |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | 4..| my_type| private   | -         | driver_handles_share_servers:False| snapshot_support:True |
 | 5..| default| public    | YES       | driver_handles_share_servers:True | snapshot_support:True |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

demo プロジェクトの demo ユーザーは種別をリスト表示できますが、my_type という名前のプライベート共有種別は表示されません。

 $ env | grep OS_
 ...
 OS_USERNAME=demo
 OS_TENANT_NAME=demo
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+----------------------------------+----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs             | optional_extra_specs |
 +----+--------+-----------+-----------+----------------------------------+----------------------+
 | 5..| default| public    | YES       | driver_handles_share_servers:True| snapshot_support:True|
 +----+--------+-----------+-----------+----------------------------------+----------------------+

管理者は、プロジェクト ID が df29a37db5ae48d19b349fe947fada46 の demo プロジェクトのプライベート共有種別へのアクセスを付与できます。

 $ env | grep OS_
 ...
 OS_USERNAME=admin
 OS_TENANT_NAME=admin
 ...
 $ openstack project list
 +----------------------------------+--------------------+
 | ID                               | Name               |
 +----------------------------------+--------------------+
 | ...                              | ...                |
 | df29a37db5ae48d19b349fe947fada46 | demo               |
 +----------------------------------+--------------------+
 $ manila type-access-add my_type df29a37db5ae48d19b349fe947fada46

その結果、demo プロジェクトのユーザーは、プライベートの共有種別を表示し、ファイル共有の作成で使用できます。

 $ env | grep OS_
 ...
 OS_USERNAME=demo
 OS_TENANT_NAME=demo
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs              | optional_extra_specs  |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | 4..| my_type| private   | -         | driver_handles_share_servers:False| snapshot_support:True |
 | 5..| default| public    | YES       | driver_handles_share_servers:True | snapshot_support:True |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

指定されたプロジェクトのアクセスを拒否するには、manila type-access-remove <share_type> <project_id> を使用します。

注記

共有種別の目的を実証する例については、2 つのバックエンドを持つ状況 (LVM をパブリックストレージとして、Ceph をプライベートストレージとして) を検討します。このような場合には、特定のプロジェクトにアクセスを許可し、user/group 認証方法によりアクセスを制御できます。

12.10. ポリシー

Shared File Systems サービス API は、ロールベースのアクセス制御ポリシーで制御されます。これらのポリシーは、どのユーザーが特定の API にどのようにアクセスできるかを決定し、サービスの policy.json ファイルで定義されます。

注記

設定ファイル policy.json はどこにも配置できます。パス /var/lib/config-data/puppet-generated/manila/etc/manila/policy.json はデフォルトで想定されています。

manila への API 呼び出しを行うたびに、ポリシーエンジンは適切なポリシー定義を使用して、呼び出しを受け入れることができるかどうかを判断します。ポリシールールは、API 呼び出しを許可する状況を決定します。ルールが空の文字列 "" の場合、/var/lib/config-data/puppet-generated/manila/etc/manila/policy.json ファイルは常にアクションが許可されるルールを持ちます。ユーザーロールまたはルールに基づくルール、ブール値式のルール。以下は、manila の policy.json ファイルのスニペットです。OpenStack リリース間で変更することが想定されます。

   {
       "context_is_admin": "role:admin",
       "admin_or_owner": "is_admin:True or project_id:%(project_id)s",
       "default": "rule:admin_or_owner",
       "share_extension:quotas:show": "",
       "share_extension:quotas:update": "rule:admin_api",
       "share_extension:quotas:delete": "rule:admin_api",
       "share_extension:quota_classes": "",
   }

ユーザーは、ポリシーで参照するグループおよびロールに割り当てられる必要があります。これは、ユーザー管理コマンドが使用されている場合にサービスによって自動的に行われます。

注記

/var/lib/config-data/puppet-generated/manila/etc/manila/policy.json への変更はすぐに有効になります。したがって、manila の稼働中に新規ポリシーを実装できます。ポリシーを手動で変更することは、予期しない副作用が発生する可能性があり、推奨されません。Manila ではデフォルトのポリシーファイルが提供されず、すべてのデフォルトポリシーがコードベース内にあります。oslopolicy-sample-generator --config-file=var/lib/config-data/puppet-generated/manila/etc/manila/manila-policy-generator.conf を実行することで、manila コードからデフォルトのポリシーを生成することができます。

第13章 オブジェクトストレージ

Object Storage (swift) サービスは、HTTP 経由でデータを保存および取得します。オブジェクト (データの塊) は、組織的な階層に保存され、匿名の読み取り専用アクセス、ACL 定義のアクセス、または一時的なアクセスを提供するように設定できます。swift は、ミドルウェアを使用して実装される複数のトークンベースの認証メカニズムをサポートします。

アプリケーションは、業界標準の HTTP RESTful API を使用して、オブジェクトストレージにデータを保存し、取得します。バックエンドの swift コンポーネントは同じ RESTful モデルに従いますが、一部の API (耐久性を管理する API など) はクラスターに対してプライベートなままになります。

swift のコンポーネントは以下のプライマリーグループに分類されます。

  • プロキシーサービス
  • 認証サービス
  • ストレージサービス

    • アカウントサービス
    • コンテナーサービス
    • オブジェクトサービス
swift ネットワークダイアグラム 1
注記

オブジェクトストレージのインストールは、インターネットに接続する必要はなく、パブリックスイッチ (組織の内部ネットワークインフラストラクチャーの一部) を持つプライベートクラウドにすることもできます。

13.1. ネットワークセキュリティー

swift のセキュリティー強化は、ネットワークコンポーネントのセキュリティー保護から始まります。詳細は、Networking の章を参照してください。

高可用性を確保する場合、rsync プロトコルがストレージサービスノード間でデータをレプリケートするために使用されます。さらに、プロキシーサービスは、クライアントエンドポイントとクラウド環境間でデータをリレーする際にストレージサービスと通信します。

注記

swift は、ノード間通信に暗号化または認証を使用しません。これは、swift がパフォーマンス上の理由でネイティブ rsync プロトコルを使用し、rsync 通信に SSH を使用しないためです。これが、アーキテクチャー図にプライベートスイッチまたはプライベートネットワーク ([V]LAN) が表示される理由です。このデータゾーンは、他の OpenStack データネットワークからも分離する必要があります。

注記

データゾーン内のストレージノードには、プライベート (V)LAN ネットワークセグメントを使用します。

これには、プロキシーノードにデュアルインターフェイス (物理または仮想) が必要です。

  • コンシューマーが到達できるパブリックインターフェイスとして 1 つのインターフェイス。
  • ストレージノードにアクセスできるプライベートインターフェイスとしての別インターフェイス。

以下の図は、Object Storage ネットワークアーキテクチャーと管理ノード (OSAM) を使用する、可能なネットワークアーキテクチャーの 1 つを示しています。

swift ネットワークダイアグラム 2

13.2. 非 root ユーザーとしてのサービスの実行

root (UID 0) 以外のサービスアカウントで実行するように swift を設定することを推奨します。1 つの推奨事項として、director によりデプロイされるように、ユーザー名を swift に、プライマリーグループを swift にすることです。Object Storage サービスには、proxy-servercontainer-serveraccount-server が含まれます。

13.3. ファイル権限

/var/lib/config-data/puppet-generated/swift/etc/swift/ ディレクトリーには、リングトポロジーと環境設定に関する情報が含まれます。以下のパーミッションが推奨されます。

chown -R root:swift /var/lib/config-data/puppet-generated/swift/etc/swift/*
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type f -exec chmod 640 {} \;
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type d -exec chmod 750 {} \;

この制限は、root だけに設定ファイルの変更を許可しますが、swift グループのメンバーシップにより、サービスにそれらの読み取りを許可します。

13.4. ストレージサービスのセキュリティー保護

以下は、さまざまなストレージサービスのデフォルトリスニングポートです。

  • アカウントサービス: TCP/6002
  • コンテナーサービス: TCP/6001
  • オブジェクトサービス: TCP/6000
  • rsync: TCP/873
注記

rsync ではなく ssync が使用される場合、耐久性を維持するためにオブジェクトサービスポートが使用されます。

注記

認証はストレージノードで発生することはありません。これらのポートのいずれかでストレージノードに接続できる場合は、認証なしでデータにアクセスしたり変更したりすることができます。この問題を軽減するには、プライベートストレージネットワークの使用に関する前述の推奨事項に従ってください。

13.5. Object Storage アカウントの用語

swift アカウントは、ユーザーアカウントまたは認証情報ではありません。定義は以下のとおりです。

  • Swift アカウント: コンテナーのコレクションです (ユーザーアカウントや認証ではない)。使用する認証システムは、アカウントに関連付けられているユーザー、およびそのアクセス方法を決定します。
  • swift コンテナー: オブジェクトのコレクション。コンテナーのメタデータは ACL で利用できます。ACL の使用は、使用される認証システムによって異なります。
  • swift オブジェクト: 実際のデータオブジェクト。オブジェクトレベルの ACL もメタデータで利用できますが、使用する認証システムに依存します。

各レベルでは、ユーザーアクセスを制御する ACL があり、ACL は使用中の認証システムを基に解釈されます。最も一般的な認証プロバイダーの種別は Identity サービス (keystone) です。カスタム認証プロバイダーも利用できます。

13.6. プロキシーサービスのセキュリティー保護

プロキシーノードには、少なくとも 2 つのインターフェイス (物理または仮想) が必要です。1 つはパブリック、および 1 つはプライベート。パブリックインターフェイスを保護するには、ファイアウォールまたはサービスのバインディングを使用できます。パブリック向けサービスは、エンドポイントのクライアント要求を処理し、認証を行い、適切なアクションを実行する HTTP Web サーバーです。プライベートインターフェイスにはリスニングサービスは必要ありませんが、代わりにプライベートストレージネットワーク上のストレージノードへの発信接続を確立するために使用されます。

13.7. HTTP リッスンポート

director は、root 以外のユーザー (UID 0 以外) で実行するように Web サービスを設定します。1024 より大きいポート番号を使用すると、Web コンテナーのいずれの部分も root として実行されなくなります。通常、HTTP REST API を使用する (そして自動認証を実行する) クライアントは、認証応答から必要な完全な REST API URL を取得します。OpenStack REST API により、クライアントはある URL に対して認証を行い、実際のサービス用に完全に異なる URL を使用するためにリダイレクトできます。たとえば、クライアントは https://identity.cloud.example.org:55443/v1/auth に対して認証を行い、認証キーおよび 、https://swift.cloud.example.org:44443/v1/AUTH_8980 のストレージ URL (プロキシーノードまたはロードバランサーの URL) を持つ応答を取得できます。

13.8. ロードバランサー

Apache を使用するオプションが実行できない場合や、パフォーマンス上の理由で TLS 作業をオフロードする場合は、専用のネットワークデバイスのロードバランサーを使用する場合があります。これは、複数のプロキシーノードを使用する場合に冗長性および負荷分散を提供する一般的な方法です。

TLS のオフロードを選択する場合は、ロードバランサーとプロキシーノード間のネットワークリンクがプライベート (V)LAN セグメント上にありるようにします。これにより、ネットワーク上の他のノード (セキュリティー侵害されている可能性がある) による非暗号化トラフィックの盗聴 (スニフィング) を防ぐことができます。このような侵害が発生した場合、攻撃者はエンドポイントクライアントまたはクラウド管理者の認証情報にアクセスし、クラウドデータにアクセスできるようになります。

使用する認証サービスは、エンドポイントクライアントへの応答で異なる URL を設定する方法を決定し、個別のプロキシーノードではなくロードバランサーを使用できるようにします。

13.9. Object Storage の認証

Object Storage (swift) は WSGI モデルを使用して、一般的な機能拡張を提供するだけではなく、エンドポイントクライアントの認証にも使用されるミドルウェア機能を提供します。認証プロバイダーは、どのロールおよびユーザー種別が存在するかを定義します。従来のユーザー名およびパスワードの認証情報を使用するものもあれば、API キートークンやクライアント側の x.509 証明書を利用するものもあります。カスタムプロバイダーは、カスタムミドルウェアを使用して統合できます。

オブジェクトストレージには、デフォルトで 2 つの認証ミドルウェアモジュールが含まれています。これらのモジュールのいずれかを、カスタム認証ミドルウェアを開発するためのサンプルコードとして使用できます。

13.10. 保存されている swift オブジェクトの暗号化

swift は、Barbican を統合して、保管されている (at-rest) オブジェクトを透過的に暗号化/復号化できます。at-rest 暗号化は、in-transit 暗号化とは異なり、ディスクに保管されている間にオブジェクトが暗号化されることを指します。

Swift はこれらの暗号化タスクを透過的に実行し、オブジェクトは swift にアップロードされる際には自動的に暗号化され、ユーザーに提供される際には自動的に復号化されます。この暗号化と復号化は、Barbican に保管されている同じ (対称) キーを使用して処理されます。

詳細は、Barbican のインテグレーションガイド (https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.2/html-single/manage_secrets_with_openstack_key_manager/) を参照してください。

13.11. その他の項目

すべてのノードの /var/lib/config-data/puppet-generated/swift/etc/swift/swift.conf に、swift_hash_path_prefix 設定および swift_hash_path_suffix 設定があります。これらは、保存されるオブジェクトのハッシュ競合の可能性を低減し、あるユーザーが別のユーザーのデータを上書きするのを防ぐために提供されます。

この値は、最初に暗号的に安全な乱数ジェネレーターで設定し、すべてのノードで一貫性を持たせる必要があります。適切な ACL で保護し、データの喪失を回避するために、バックアップコピーを作成するようにします。

第14章 監視およびロギング

ログ管理は、OpenStack デプロイメントのセキュリティーステータスを監視する重要なコンポーネントです。ログは、OpenStack デプロイメントを設定するコンポーネントのアクティビティーに加えて、管理者、プロジェクト、およびインスタンスの BAU アクションに関する洞察を提供します。

ログは、予防的なセキュリティー活動および継続的なコンプライアンスアクティビティーのみならず、調査およびインシデントへの対応に関する貴重な情報ソースでもあります。たとえば、keystone アクセスログを分析すると、その他の関連情報に加えて、ログインの失敗、その頻度、送信元 IP、およびイベントが特定のアカウントに限定されるかどうかなどについて、警告が得られます。

director には、AIDE を使用した侵入検知機能、および keystone の CADF 監査が含まれています。詳細は、インフラストラクチャーおよび仮想化の強化 を参照してください。

14.1. モニタリングインフラストラクチャーの強化

集中ロギングシステムは、侵入者にとって価値のあるターゲットです。侵入に成功すると、イベントの記録を消去または改ざんできるからです。この点を考慮に入れて、モニタリングプラットフォームを強化することが推奨されます。さらに、機能停止またはサービス拒否 (DoS) 攻撃に備えて、フェイルオーバーの計画を作成すると共に、このシステムのバックアップを定期的に作成することを検討してください。

14.2. 監視するイベントの例

イベントの監視は、環境を保護し、リアルタイムの検出および応答を提供するより予防的な手段です。監視に役立つツールが複数存在します。OpenStack のデプロイメントでは、ハードウェア、OpenStack サービス、およびクラウドリソースの使用状況をモニターする必要があります。

本セクションでは、認識する必要のあるイベントの例について説明します。

重要

このリストがすべてを網羅している訳ではありません。実際のネットワークに適用される可能性のある追加のユースケースを考慮する必要があります。また、異常な動作を考慮する必要があります。

  • ログが生成されないことを検出するのは、価値の高いイベントです。このようなギャップは、サービス障害や、攻撃を隠すために侵入者が一時的にログを停止したり、ログレベルを変更したりしたことを示す場合があります。
  • スケジュールされていないイベントの開始や停止などのアプリケーションイベントは、セキュリティーと何らかの関係がある可能性があります。
  • ユーザーのログインや再起動などの OpenStack ノードでのオペレーティングシステムイベントこれにより、システムの適切な使用方法と不適切な使用方法を区別するための、貴重な洞察が得られます。
  • ネットワークブリッジがダウンする。これは、サービスが停止するリスクがあるため、対処を要するイベントです。
  • コンピュートノードでの IPtable のフラッシュイベント、およびそれに伴うインスタンスへのアクセス不能

Identity サービス内のユーザー、プロジェクト、またはドメインの削除により使用されなくなったインスタンスからのセキュリティーリスクを軽減するには、システム内で通知を生成し、OpenStack コンポーネントに適切にこれらのイベントに応答させます (例: インスタンスの切断、攻撃を受けたボリュームの接続解除、CPU およびストレージリソースの再確保など)。

侵入検知ソフトウェア、ウイルス対策ソフトウェア、およびスウェアウェアの検出や削除ユーティリティーなどのセキュリティー監視は、攻撃または侵入がいつどのように発生したかを示すログを生成することができます。これらのツールは、OpenStack ノードにデプロイすると、保護のレイヤーを提供します。プロジェクトユーザーも、このようなツールをインスタンスで実行する必要があります。

第15章 プロジェクトのデータのプライバシー

OpenStack は、異なるデータ要件を持つプロジェクト間のマルチテナンシーをサポートするように設計されています。クラウドオペレーターは、適用可能なデータのプライバシーに関する懸念点と規制を考慮する必要があります。本章では、OpenStack デプロイメントにおけるデータ保持および破棄の要素に対応しています。

15.1. データ保持

データのプライバシーと分離は、過去数年にクラウド導入に対する主要なバリアとして、一貫して引用されています。クラウド内で誰がデータを所有するのか、クラウドオペレーターが究極的にこのデータの管理者として信頼できるかどうかの懸念が、これまで重大な問題となっていました。

特定の OpenStack サービスは、プロジェクトに属するデータおよびメタデータ、または参考プロジェクト情報にアクセスできます。たとえば、OpenStack クラウドに保存されるプロジェクトデータには、以下の項目が含まれます。

  • Object Storage オブジェクト
  • コンピュートインスタンスの一時ファイルシステムのストレージ
  • コンピュートインスタンスのメモリー
  • Block Storage ボリュームデータ
  • Compute アクセス用の公開鍵
  • Image サービスの仮想マシンイメージ
  • インスタンスのスナップショット
  • Compute の configuration-drive 拡張に渡されるデータ

OpenStack クラウドにより保存されるメタデータには、以下の項目が含まれます (このリストがすべてを網羅している訳ではありません)。

  • 組織名
  • ユーザーの本名
  • 実行中のインスタンス、バケット、オブジェクト、ボリューム、およびその他のクォータ関連項目の数またはサイズ
  • インスタンスの実行時間またはデータの保存時間
  • ユーザーの IP アドレス
  • コンピュートイメージのバンドル用に内部的に生成された秘密鍵

15.2. データの破棄

オペレーターは、廃棄の前に、組織の管理から外す前に、または再使用のために解放する前に、クラウドシステムメディア (デジタルおよび非デジタル) をサニタイズする必要があります。サニタイズ方法は、その情報の具体的なセキュリティードメインおよび機密性に対し、適切な強度および整合性のレベルを実装する必要があります。

注記

NIST Special Publication 800-53 Revision 4 に、本トピックが具体的に説明されています。

The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal.

クラウドオペレーターは、データ破棄およびサニタイズに関する一般的なガイドラインを開発する場合は、以下を考慮してください (NIST の推奨セキュリティー制御に基づく)。

  • メディアサニタイズおよび破棄アクションを追跡、文書化、および検証する。
  • サニタイズ機器と手順をテストして、適切なパフォーマンスを確認する。
  • ポータブル、リムーバブルストレージデバイスデバイスをクラウドインフラストラクチャーに接続する前に、これらのデバイスをサニタイズする。
  • サニタイズができないクラウドシステムメディアを破棄する。

その結果、OpenStack のデプロイメントで以下のプラクティスを対処する必要があります (一例)。

  • セキュアなデータイレイジャー
  • インスタンスメモリーのスクラブ
  • Block Storage ボリュームデータ
  • コンピュートインスタンスの一時ストレージ
  • ベアメタルサーバーのサニタイズ

15.2.1. 安全に消去されないデータ

OpenStack の一部のデータは削除される可能性がありますが、上記の NIST 規格のコンテキストでは安全に消去されません。通常、これは、データベースに保存されている上記のメタデータと情報の多くまたはすべてに適用できます。これは、自動バキュームおよび定期的な空き領域の消去のためのデータベースやシステム設定で修正される可能性があります。

15.2.2. インスタンスメモリーのスクラブ

さまざまなハイパーバイザーに固有のことは、インスタンスメモリーの取り扱いです。一般に、インスタンスの削除時もしくは作成時に、またはその両方で、ハイパーバイザーはベストエフォートでメモリーのスクラブを行うと考えられますが、この動作は Compute では定義されません。

15.3. cinder ボリュームデータの暗号化

OpenStack のボリューム暗号化機能の使用を強く推奨します。詳細は、下記データの暗号化セクションのボリュームの暗号化で説明されています。この機能が使用される場合、暗号鍵を安全に削除することでデータの破棄が実行されます。エンドユーザーは、ボリュームの作成時にこの機能を選択できますが、管理者はまず 1 度限りのボリューム暗号化機能の設定を実行する必要があることに注意してください。

OpenStack のボリューム暗号化機能が使用されていない場合、他のアプローチは通常有効にすることが困難になります。バックエンドプラグインが使用されている場合は、独立した暗号化方法や標準以外の上書きソリューションある可能性があります。OpenStack Block Storage へのプラグインでは、さまざまな方法でデータを保管します。多くのプラグインはベンダーや技術に固有のものですが、その他はファイルシステム (LVM または ZFS など) に関するより DIY 的なソリューションです。データを安全に破棄する方法は、プラグイン、ベンダー、およびファイルシステムによって異なります。

一部のバックエンド (ZFS など) は、データの公開を防ぐためにコピーオンライトをサポートします。このような場合、書き込まれていないブロックから読み取ると、常にゼロを返します。他のバックエンド (LVM など) はこれをネイティブにサポートしていない可能性があるため、cinder プラグインは、ブロックをユーザーに渡す前に以前に書き込まれたブロックを上書きします。選択したボリュームバックエンドが提供する保証を確認することや、提供されない保証についてどのような修復が利用できるかを確認することが重要です。

15.4. Image サービスの削除遅延機能

Image サービスには削除遅延機能があり、定義された期間イメージの削除を保留します。この動作がセキュリティー上の問題である場合は、この機能を無効にすることを検討してください。glance-api.conf ファイルを編集して delayed_delete オプションを False に設定すると、この機能を無効にすることができます。

15.5. Compute のソフト削除機能

Compute にはソフト削除機能があり、定義した期間、削除されるインスタンスをソフト削除状態にすることができます。この期間は、インスタンスを復元することができます。ソフト削除機能を無効にするには、/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf ファイルを編集し、reclaim_instance_interval オプションを空のままにします。

15.6. ベアメタルプロビジョニングのセキュリティー強化

ベアメタルプロビジョニングインフラストラクチャーの場合、一般的にはベースボード管理コントローラー (BMC)、特に IPMI のセキュリティー強化を検討する必要があります。たとえば、プロビジョニングネットワーク内のこれらのシステムを分離し、デフォルト以外の強力なパスワードを設定し、不要な管理機能を無効にします。詳細は、これらのコンポーネントのセキュリティーの強化に関するベンダーのガイダンスを参照してください。

注記

可能な場合は、レガシーに代えて Redfish ベースの BMC の評価を検討してください。

15.7. ハードウェアの特定

サーバーをデプロイする場合、攻撃者のサーバーと区別するための信頼できる方法が常にあるとは限りません。この機能は、ある程度ハードウェア/BMC に依存する可能性がありますが、通常は立証可能な手段はサーバーに組み込まれていないようです。

15.8. データの暗号化

プロジェクトデータがディスクのどこに保存されていても、あるいはネットワークを通じて転送されていても、実装者にはデータを暗号化するためのオプションがあります。たとえば、以下で説明されている OpenStack ボリューム暗号化機能です。これは、プロバイダーに送信する前にユーザーが自分のデータを暗号化する一般的な推奨事項を上回るものです。

プロジェクトの代わりにデータを暗号化することの重要性は、攻撃者がプロジェクトデータにアクセスできるというプロバイダーによって想定されるリスクに非常に関係します。政府、ポリシー、私的な契約、またはパブリッククラウドプロバイダーの私的な契約に関する法的な要件があります。プロジェクトの暗号化ポリシーを選択する前に、リスク評価と法的アドバイスを取得することを検討してください。

インスタンスまたはオブジェクトごとの暗号化が、降順、プロジェクト、ホスト、およびクラウドアグリゲーションごとよりも優先されます。この推奨事項は、実装の複雑性と困難度とは逆です。現時点で、一部のプロジェクトでは、プロジェクトごとの粗い粒度での暗号化を実装することが困難、または不可能な場合があります。実装者は、プロジェクトデータの暗号化に深刻な考慮事項を与えます。

多くの場合、データの暗号化は、単にキーを廃棄することで、プロジェクトやインスタンスごとのデータを確実に破棄する機能に貢献します。このようにすると、信頼できる安全な方法でこれらのキーを破棄することが非常に重要になります。

ユーザーのデータを暗号化する機会が存在します。

  • Object Storage オブジェクト
  • ネットワークデータ

15.8.1. ボリュームの暗号化

OpenStack のボリューム暗号化機能は、プロジェクトごとにプライバシーをサポートします。以下の機能がサポートされます。

  • Dashboard またはコマンドラインインターフェイスから開始された暗号化されたボリューム種別の作成および使用
  • 暗号化を有効にし、暗号化アルゴリズムやキーサイズなどのパラメーターを選択します。
  • iSCSI パケットに含まれるボリュームデータの暗号化
  • 元のボリュームが暗号化されている場合、暗号化されたバックアップをサポートします。
  • Dashboard には、ボリューム暗号化のステータスが表示されます。ボリュームが暗号化されていること、およびアルゴリズムやキーサイズなどの暗号化パラメーターが含まれます。
  • 鍵管理サービスとのインターフェイス

15.8.2. Object Storage オブジェクト

Object Storage (swift) は、ストレージノードに保管されているオブジェクトデータのオプション暗号化をサポートします。オブジェクトデータの暗号化は、承認されていないユーザーがディスクへの物理アクセスを取得している場合に、ユーザーのデータが読み取られるリスクを軽減することを目的としています。

保管されているデータの暗号化は、プロキシーサーバー WSGI パイプラインに含まれる可能性のあるミドルウェアにより実装されます。この機能は swift クラスターに内部にあり、API 経由で公開されません。クライアントは、swift サービス内のこの機能によりデータが暗号化されていることを認識しません。内部で暗号化されたデータは swift API 経由でクライアントに返されません。

swift で保管されている間、以下のデータは暗号化されます。

  • オブジェクトコンテンツ (例: オブジェクト PUT 要求ボディーのコンテンツ)。
  • ゼロ以外のコンテンツを持つオブジェクトのエンティティータグ (ETag)。
  • すべてのカスタムユーザーオブジェクトのメタデータ値。たとえば、 PUT または POST リクエストで、X-Object-Meta- の接頭辞が付けられたヘッダーを使用して送信されるメタデータなどです。

上記のリストに含まれていないデータまたはメタデータは暗号化されません。以下に例を示します。

  • アカウント、コンテナー、およびオブジェクト名
  • アカウントおよびコンテナーのカスタムユーザーメタデータの値
  • すべてのカスタムユーザーメタデータ名
  • オブジェクトコンテンツ種別の値
  • オブジェクトサイズ
  • システムメタデータ

15.8.3. Block Storage のパフォーマンスおよびバックエンド

オペレーティングシステムを有効にすると、Intel と AMD の両方のプロセッサーで利用可能なハードウェアアクセラレーション機能を使用して、OpenStack Volume Encryption のパフォーマンスを向上させることができます。

OpenStack のボリューム暗号化機能は、ホスト上の dm-crypt またはネイティブの QEMU 暗号化サポートを使用してボリュームデータを保護します。Red Hat は、暗号化ボリュームを作成する際に LUKS ボリューム暗号化タイプを使用することを推奨します。

15.8.4. ネットワークデータ

コンピュートノードのプロジェクトデータは IPsec または他のトンネルで暗号化される可能性があります。これは、OpenStack では一般的または標準ではありませんが、興味のある実装者が利用可能なオプションです。同様に、ネットワーク上で転送されるため、暗号化されたデータは暗号化された状態のままです。

15.9. キー管理

プロジェクトデータのプライバシーに関する頻出する懸念に対処するために、OpenStack コミュニティーでは、データの暗号化をより広範囲で行うことに大きな関心が寄せられています。クラウドに保存する前にエンドユーザーがデータを暗号化するのは比較的簡単です。メディアファイルやデータベースアーカイブなどのプロジェクトオブジェクトに関して、実行可能なパスがあります。一部では、クライアント側の暗号化は、今後の使用のためにデータを復号化するために、鍵の提示などのクライアントの連携を必要とする仮想化技術で保持されるデータの暗号化に使用されます。

barbican を使用すると、プロジェクトがデータをシームレスに暗号化し、キー管理でユーザーに負担をかけることなくデータにアクセスすることができます。OpenStack の一部として暗号化およびキー管理サービスを提供することにより、保管データのセキュリティー確保の採用が促進され、データのプライバシーや誤用に関するお客様の懸念に対処するのに役立ちます。

ボリューム暗号化機能は、Key Manager サービス (バービカン) などのキー管理サービスを使用しており、キーの作成とセキュリティー保護された保存を行います。

第16章 インスタンスのセキュリティーの管理

仮想化環境でインスタンスを実行する利点の 1 つは、通常ベアメタルへのデプロイ時に利用できないセキュリティー制御の新しい機会です。OpenStack デプロイメントの情報セキュリティーを向上させる特定のテクノロジーを仮想化スタックに適用できます。セキュリティー要件が強固な運用者は、これらの技術のデプロイを検討する必要がある場合がありますが、すべての状況に該当する訳ではありません。場合によっては、規定されたビジネス要件により、クラウドでの使用にテクノロジーを除外できる場合があります。同様に、一部の技術は、動作状態などのインスタンスデータを検査しますが、システムのユーザーにとって望ましくない可能性があります。

本章では、これらのテクノロジーと、インスタンスまたは基盤のノードのセキュリティーを強化するために使用できる状況について説明します。プライバシーの懸念事項も詳しく説明します。これには、データパススルー、イントロスペクション、またはエントロピーソースが含まれます。

16.1. インスタンスへのエントロピーの提供

エントロピーとは、インスタンスで利用可能なランダムデータの質とソースのことです。暗号技術は一般的にランダム性に依存しており、エントロピーのプールから抽出する必要があります。エントロピーの枯渇は、暗号技術に必要なランダム性をサポートするのに十分なエントロピーをインスタンスが得られない場合に起こります。エントロピーの枯渇は、一見すると関係のないものとして現れることがあります。たとえば、インスタンスが SSH キーの生成を待機していることが原因で、起動時間が遅くなる可能性があります。また、エントロピーが枯渇すると、クラウドのユーザーがインスタンス内の質の悪いエントロピーソースを使用することになり、クラウド上で動作するアプリケーションの安全性が低下します。

高品質のエントロピー源をインスタンスに提供するためには、インスタンスをサポートするのに十分な数のハードウェア乱数生成器 (HRNG) がクラウドに必要です。日常的な運用であれば、最新の HRNG は 50 ~ 100 台の Compute ノードをサポートするのに十分なエントロピーを生成することができます。高帯域の HRNG は、より多くのノードを扱うことができます。十分なエントロピーを確保するためには、クラウドのアプリケーション要件を特定する必要があります。

VirtIO RNG は、デフォルトで /dev/urandom をエントロピーソースとして使用する乱数生成器で、起動時にインスタンスでエントロピーが枯渇しないようにします。また、デプロイメント全体でエントロピーを配布する方法を提供するために、HRNG またはエントロピー収集デーモン (EGD) などのツールを使用するように設定することもできます。Virtio RNG デバイスは、インスタンスのデフォルトで有効になっています。インスタンスで Virtio RNG デバイスを無効にするには、インスタンスフレーバーで hw_rng:allowedFalse に設定する必要があります。

16.2. ノードへのインスタンスのスケジューリング

インスタンスを作成する前に、イメージのインスタンス化のホストを選択する必要があります。この選択は、コンピュートおよびボリューム要求のディスパッチ方法を決定する nova-scheduler により行われます。

FilterScheduler は Compute のデフォルトスケジューラーですが、他のスケジューラーが存在します。この機能は、フィルターヒント と協力して、インスタンスの開始場所を決定します。ホスト選択のこのプロセスにより、管理者はさまざまなセキュリティーおよびコンプライアンス要件を満たすことができます。データの分離が主な懸念である場合は、可能な場合は同じホストにプロジェクトインスタンスを配置することができます。逆に、インスタンスの可用性やフォールトトレランスの理由で、できるだけ異なるホストにインスタンスを配置することができます。

フィルタースケジューラーは、以下の主要なカテゴリーに分類されます。

  • リソースベースのフィルター: ハイパーバイザーホストセットのシステムリソース使用状況に基づいてインスタンスの配置を決定し、RAM、IO、CPU 使用率などの空きまたは使用されるプロパティーで起動することができます。
  • イメージベースのフィルター: 仮想マシンのオペレーティングシステムや使用するイメージの種別など、使用されるイメージメタデータに基づいて、インスタンスの作成を委譲します。
  • 環境ベースのフィルター: 特定の IP 範囲内、アベイラビリティーゾーン間、または別のインスタンスと同じホストなど、外部の詳細に基づいてインスタンスの配置を決定します。
  • カスタム基準: 信頼やメタデータの解析などの、ユーザーまたは管理者が提供する基準に基づいて、インスタンスの作成を委譲します。

複数のフィルターを一度に適用できます。たとえば、ServerGroupAffinity フィルターは、特定のホストセットのメンバーにインスタンスが作成されていることを確認し、ServerGroupAntiAffinity フィルターは同じインスタンスが別の特定ホストセットで作成されないことを確認します。これら 2 つのフィルターは通常同時に有効になり、互いに競合しないことに注意してください。特定のプロパティーの値をチェックし、いずれも同時に true にできないためです。

filteringWorkflow1
重要

ユーザーが提供するオブジェクトまたは操作可能なオブジェクト (メタデータなど) を解析するフィルターを無効にすることを検討してください。

16.3. 信頼できるイメージの使用

クラウド環境では、ユーザーは事前にインストール済みのイメージまたは自身がアップロードするイメージと連携します。いずれの場合も、使用するイメージが改ざんされていないことを確認できる必要があります。イメージを検証する機能は、セキュリティーに関する基本的な必須要件です。イメージのソースから使用される宛先まで、信頼チェーンが必要です。これは、信頼できるソースから取得したイメージを署名し、使用する前に署名を確認して実行できます。検証されたイメージを取得し、作成する各種の方法について以下に説明し、続いてイメージ署名の検証機能について説明します。

16.4. イメージの作成

OpenStack のドキュメントでは、イメージを作成して Image サービスにアップロードする方法についてのガイダンスを提供します。また、ゲストオペレーティングシステムをインストールおよび強化するプロセスがあることが前提となります。以下の項目は、イメージを OpenStack に転送する方法に関する補足情報を提供します。イメージを取得するオプションは複数あります。それぞれは、イメージの由来を検証するのに役立つ特定のステップを持ちます。

  • オプション 1: 信頼されたソースからブートメディアを取得します。たとえば、公式の Red Hat ソースからイメージをダウンロードしてから、追加のチェックサム検証を実行できます。
  • オプション 2: OpenStack Virtual Machine Image Guide を使用します。この場合、組織の OS 強化ガイドラインに従うようにしてください。
  • オプション 3: 自動化されたイメージビルダーを使用します。以下の例では、Oz イメージビルダーを使用します。OpenStack コミュニティーは、最近 disk-image-builder という新しいツールを作成しました。ただし、セキュリティー評価はまだ実施されていません。

この例では、RHEL 6 CCE-26976-1 は、Oz 内に NIST 800-53 Section AC-19(d) を実装するのに役立ちます。

<template>
<name>centos64</name>
<os>
  <name>RHEL-6</name>
  <version>4</version>
  <arch>x86_64</arch>
  <install type='iso'>
  <iso>http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso</iso>
  </install>
  <rootpw>CHANGE THIS TO YOUR ROOT PASSWORD</rootpw>
</os>
<description>RHEL 6.4 x86_64</description>
<repositories>
  <repository name='epel-6'>
  <url>http://download.fedoraproject.org/pub/epel/6/$basearch</url>
  <signed>no</signed>
  </repository>
</repositories>
<packages>
  <package name='epel-release'/>
  <package name='cloud-utils'/>
  <package name='cloud-init'/>
</packages>
<commands>
  <command name='update'>
  yum update
  yum clean all
  sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
  echo -n > /etc/udev/rules.d/70-persistent-net.rules
  echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules
  chkconfig --level 0123456 autofs off
  service autofs stop
  </command>
</commands>
</template>

イメージの手動のビルドプロセスは複雑で、エラーが発生する可能性があるため、避けてください。さらに、イメージのビルドに Oz などの自動化システム、または起動後のイメージのハードニングのための設定管理ユーティリティー (Chef または Puppet など) を使用すると、一貫したイメージを作成したり、長期に渡りベースイメージが対応する強化ガイドラインに準拠していることを追跡したりできます。

パブリッククラウドサービスをサブスクライブする場合には、クラウドプロバイダーで、デフォルトのイメージを生成するために使用するプロセスの概要を確認する必要があります。プロバイダーで独自のイメージをアップロードできる場合、インスタンスを作成するためにイメージを使用する前に、イメージが変更されていないことを確認できる必要があります。これを行うには、イメージ署名の確認の以下のセクションまたは、署名を使用できない場合は以下の段落を参照してください。

Image サービス (glance) は、ノード上の Compute サービスにイメージをアップロードするために使用されます。この転送は、TLS 経由でさらに強化する必要があります。イメージがノード上にあると、これは基本的なチェックサムでチェックされ、そのディスクは起動されるインスタンスのサイズに基づいて拡張されます。後で、このノードで同じインスタンスサイズで同じイメージを起動すると、同じ拡張イメージから起動されます。この拡張されたイメージは起動前にデフォルトで再検証されないため、改ざんされたリスクがあります。ファイルの手動検査が、作成されるイメージで実行されていない限り、ユーザーは改ざんを認識しません。これを軽減するには、イメージの署名の確認トピックで以下のセクションを参照してください。

16.5. イメージの署名の確認

イメージの署名検証を有効にして、Compute サービス (nova) がインスタンスを開始する前に、Image Service (glance) のイメージに不正な変更が含まれていないことを確認できます。この機能を有効にすると、マルウェアやセキュリティーの脆弱性が含まれる可能性のある新しいインスタンスが起動できなくなります。

手順

  1. Heat テンプレートで、VerifyGlanceSignatures パラメーターに True の値を設定して、インスタンスの署名検証を有効にします。

    parameter_defaults:
        VerifyGlanceSignatures: True
  2. VerifyGlanceSignatures パラメーターの変更に使用するテンプレートが openstack overcloud デプロイ スクリプトに含まれていることを確認し、デプロイスクリプトを再実行します。
注記

署名していないイメージでインスタンスを作成すると、イメージは検証に失敗し、インスタンスは起動しません。イメージへの署名の詳細は、Image Service のイメージへの署名 を参照してください。

16.6. インスタンスの移行

OpenStack と基礎となる仮想化層は、OpenStack ノード間のイメージのライブマイグレーションを提供するため、インスタンスのダウンタイムなしに、コンピュートノードのローリングアップグレードをシームレスに実行できます。ただし、ライブマイグレーションでは、大きなリスクも伴います。リスクを理解するため、ライブマイグレーション中に実行される手順の概要を以下に示します。

  1. 移行先ホストでインスタンスを起動する
  2. メモリーを転送する
  3. ゲストを停止してディスクの同期する
  4. 状態を遷移する
  5. ゲストを起動する
注記

コールドマイグレーション、サイズ変更、退避などの特定の操作により、インスタンスのデータをネットワークを通じて他のサービスに転送することになります。

16.6.1. ライブマイグレーションのリスク

ライブマイグレーションプロセスのさまざまな段階では、インスタンスのランタイムメモリーとディスクの内容は、ネットワークを通じてプレーンテキストで送信されます。したがって、ライブマイグレーションの使用時には、対応する必要があるリスクが複数含まれています。以下は、これらのリスクについて詳しく説明します (すべてを網羅している訳ではありません。)。

  • サービス妨害 (DoS): 移行プロセス中に何らかの障害が発生した場合、インスタンスは失われる可能性があります。
  • データ漏えい: メモリーまたはディスク転送は安全に処理する必要があります。
  • データ操作: メモリーまたはディスク転送が安全に処理されない場合、攻撃者は移行中にユーザーデータを操作できます。
  • コード挿入: メモリーまたはディスク転送が安全に処理されない場合、攻撃者は移行中にディスクまたはメモリーいずれかの実行ファイルを操作できます。

16.6.2. ライブマイグレーションの無効化

現時点で、OpenStack ではデフォルトでライブマイグレーションが有効になっています。ライブマイグレーションは、デフォルトでは管理者専用タスクであるため、ユーザーはこの操作を開始できず、管理者 (信頼されると考えられる) しか開始できません。policy.json ファイルに以下の行を追加して、ライブマイグレーションを無効にすることができます。

"compute_extension:admin_actions:migrate": "!",
"compute_extension:admin_actions:migrateLive": "!",

あるいは、TCP ポート 49152 から 49261 までブロックする、または、nova ユーザーにコンピュートホスト間でのパスワードなしの SSH アクセスが含まれないようにすると、ライブマイグレーションに失敗することが期待されます。

ライブマイグレーションの SSH 設定は大幅にロックされていることに注意してください。新しいユーザーが作成され (nova_migration)、SSH キーがそのユーザーに制限され、許可されているネットワークでのみ使用されます。次に、ラッパースクリプトは実行可能なコマンド (例: libvirt ソケット上の netcat) を制限します。

16.6.3. 暗号化されたライブマイグレーション

ライブマイグレーションのトラフィックは、実行中のインスタンスのディスクおよびメモリーのコンテンツをプレーンテキストで転送し、デフォルトでは内部 API ネットワークでホストされています。

ライブマイグレーションを有効にするのに十分な要件 (アップグレードなど) がある場合、libvirtd はライブマイグレーション用に暗号化されたトンネルを提供できます。ただし、この機能は OpenStack Dashboard または nova-client コマンドで公開されず、libvirtd の手動設定でのみアクセスできます。ライブマイグレーションプロセスは、以下の手順概要に変わります。

  1. インスタンスデータがハイパーバイザーから libvirtd にコピーされます。
  2. 移行元ホストと移行先ホストの両方で libvirtd プロセス間で暗号化されたトンネルが作成されます。
  3. 移行先の libvirtd ホストは、インスタンスを基礎となるハイパーバイザーにコピーして戻します。
注記

Red Hat OpenStack Platform 13 では、推奨されるアプローチはトンネル化された移行を使用することで、ceph をバックエンドとして使用する場合にデフォルトで有効化されます。詳細は、https://docs.openstack.org/nova/queens/configuration/config.html#libvirt.live_migration_tunnelled を参照してください。

16.7. モニタリング、アラート、およびレポート

インスタンスは、ホスト間で複製可能なサーバーイメージです。したがって、物理ホストと仮想ホスト間と同様にロギングを適用することが推奨されます。ホストやデータへのアクセスイベント、ユーザーの追加および削除、権限の変更、要件で規定されるその他のイベントなどのオペレーティングシステムやアプリケーションイベントをログに記録する必要があります。結果をログアグリゲーターにエクスポートすることを検討してください。ログアグリゲーターは、ログイベントを収集し、解析用に関連付け、参照または今後のアクション用に保管します。これを実行するための一般的なツールの 1 つは、ELK スタックまたは Elasticsearch、Logstash、および Kibana です。

注記

これらのログは、定期的に確認したり、ネットワークオペレーションセンター (NOC) によって実行されるライブビュー内で監視する必要もあります。

さらに、どのイベントがその後にアクションのレスポンダーに送信されるアラートのトリガーになるかを把握する必要があります。

詳細は、監視ツール設定ガイド を参照してください。

16.8. 更新およびパッチ

ハイパーバイザーは、独立した仮想マシンを実行します。このハイパーバイザーは、オペレーティングシステム内または直接 (ベアメタルと呼ばれる) ハードウェア上で実行できます。ハイパーバイザーの更新は、仮想マシンに伝播されません。たとえば、デプロイメントが KVM を使用し、CentOS 仮想マシンのセットがある場合、KVM への更新では CentOS 仮想マシンで実行されているものは更新されません。

仮想マシンの明確な所有権を所有者に割り当て、その所有者が仮想マシンの強化、デプロイメント、および継続する機能を実施することを検討してください。また、更新を定期的にデプロイする計画を作成し、最初に実稼働環境と類似する環境でテストする必要があります。

16.9. ファイアウォールおよびインスタンスプロファイル

最も一般的なオペレーティングシステムには、追加のセキュリティー層用のホストベースのファイアウォールが含まれています。インスタンスはできるだけ少ないアプリケーションを実行すべきで (可能な場合、単一目的のインスタンスの観点で)、インスタンス上で実行されているすべてのアプリケーションは、アプリケーションがアクセスする必要のあるシステムリソース、それの実行に必要な権限の最低レベル、および仮想マシンから送受信されると予想されるネットワークトラフィックを決定するために、プロファイリングする必要があります。この予想されるトラフィックは、SSH または RDP などの必要なロギングおよび管理通信と共に、許可されるトラフィックとしてホストベースのファイアウォールに追加する必要があります。その他のトラフィックは、すべてファイアウォール設定で明示的に拒否する必要があります。

Linux インスタンスでは、上記のアプリケーションプロファイルを、audit2allow などのツールと併用して、ほとんどの Linux ディストリビューションで機密システム情報をさらに保護する SELinux ポリシーを構築することができます。SELinux は、ユーザー、ポリシー、およびセキュリティーコンテキストの組み合わせを使用して、アプリケーションの実行に必要なリソースを区分し、必要のない他のシステムリソースから分離します。

注記

Red Hat OpenStack Platform では、OpenStack サービス用にカスタマイズされるポリシーと共に、デフォルトで SELinux が有効化されます。必要に応じて、これらのポリシーを定期的に確認することを検討してください。

16.10. セキュリティーグループ

OpenStack は、特定のプロジェクトのインスタンスに厚い防御を追加するために、ホストとネットワークの両方にセキュリティーグループを提供します。これらは、ポート、プロトコル、およびアドレスに基づいて着信トラフィックを許可または拒否するため、ホストベースのファイアウォールと似ています。ただし、ホストベースのファイアウォールルールは、着信トラフィックと送信トラフィックの両方に適用できますが、セキュリティーグループルールは、着信トラフィックにのみ適用されます。ホストおよびネットワークセキュリティーグループルールが競合して、正当なトラフィックを拒否することもあります。使用されているネットワークに対して、セキュリティーグループが正しく設定されていることを確認することを検討してください。詳細は、本ガイドのセキュリティーグループを参照してください。

注記

特に無効にする必要がある場合を除き、セキュリティーグループおよびポートセキュリティーを有効なままにしておくべきです。厚い防御のアプローチを構築するには、インスタンスに細かな粒度のルールを適用することが推奨されます。

16.11. インスタンスのコンソールへのアクセス

デフォルトでは、インスタンスのコンソールには仮想コンソールからリモートでアクセスできます。これは、トラブルシューティングに役立ちます。Red Hat OpenStack Platform は、リモートコンソールアクセスに VNC を使用します。

  • ファイアウォールルールを使用して VNC ポートをロックダウンすることを検討してください。デフォルトでは、nova_vnc_proxy608013080 を使用します。
  • VNC トラフィックが TLS で暗号化されていることを確認します。director ベースのデプロイメントの場合は、UseTLSTransportForVnc で開始します。

16.12. 証明書の挿入

インスタンスに SSH 接続する必要がある場合は、作成時に必要な SSH 鍵をインスタンスに自動的に挿入するよう Compute を設定することができます。

詳細は、Creating an image を参照してください。

第17章 メッセージキュー

メッセージキューサービスは、OpenStack でのプロセス間通信を容易にします。これは、以下のメッセージキューサービスのバックエンドを使用して行われます。

  • RabbitMQ: Red Hat OpenStack Platform はデフォルトで RabbitMQ を使用します。
  • Qpid

RabbitMQ と Qpid はいずれも Advanced Message Queuing Protocol (AMQP) フレームワークで、ピアツーピア通信用のメッセージキューを提供します。キューの実装は、通常、キューサーバーの集中的または分散プールとしてデプロイされます。

メッセージキューは、OpenStack デプロイメント全体にわたるコマンドおよび制御機能を効果的に容易化します。キューへのアクセスが許可されたら、それ以上の承認チェックは実行されません。キュー経由でアクセス可能なサービスは、実際のメッセージペイロード内のコンテキストおよびトークンを検証します。ただし、トークンは再使用でき、インフラストラクチャー内の他のサービスを承認できるため、トークンの有効期限に注意してください。

OpenStack は、メッセージ署名などのメッセージレベルの機密性をサポートしません。したがって、メッセージトランスポート自体をセキュア化し、認証する必要があります。高可用性 (HA) 設定には、キューツーキュー認証および暗号化を実行する必要があります。

17.1. メッセージングトランスポートのセキュリティー

AMQP ベースのソリューション (Qpid および RabbitMQ) は、TLS を使用したトランスポートレベルのセキュリティーをサポートします。

メッセージキューのトランスポートレベルの暗号化を有効にすることを検討してください。メッセージングクライアント接続に TLS を使用すると、メッセージングサーバーへの改ざんおよび盗聴から通信を保護することができます。以下のガイダンスは、TLS が一般的な 2 つのメッセージングサーバー (Qpid および RabbitMQ) 用にどのように設定されているかに関するものです。メッセージングサーバーがクライアント接続を検証するために使用する信頼できる認証局 (CA) バンドルを設定する場合は、これをノードに使用される CA のみに制限することが推奨されます (内部管理 CA が推奨されます)。信頼された CA のバンドルは、承認されるクライアント証明書を決定し、TLS 接続の設定のクライアント-サーバー検証手順をスキップします。

注記

証明書と鍵ファイルをインストールする場合は、ファイルパーミッションが制限されており (たとえば、chmod 0600 を使用)、メッセージングサーバーの他のプロセスやユーザーによる不正アクセスを阻止するために、その所有権がメッセージングサーバーのデーモンユーザーに制限されるようにしてください。

17.1.1. RabbitMQ サーバーの SSL 設定

以下の行をシステム全体の RabbitMQ 設定ファイル (通常は /etc/rabbitmq/rabbitmq.config) に追加する必要があります。

[
  {rabbit, [
     {tcp_listeners, [] },
     {ssl_listeners, [{"<IP address or hostname of management network interface>", 5671}] },
     {ssl_options, [{cacertfile,"/etc/ssl/cacert.pem"},
                    {certfile,"/etc/ssl/rabbit-server-cert.pem"},
                    {keyfile,"/etc/ssl/rabbit-server-key.pem"},
                    {verify,verify_peer},
                    {fail_if_no_peer_cert,true}]}
   ]}
].
注記

SSL 以外のポートでリッスンしないように、tcp_listeners オプションは [] に設定します。サービスの管理ネットワークでのみリッスンするように、ssl_listeners オプションは制限する必要があります。

17.2. キュー認証およびアクセス制御

RabbitMQ および Qpid は、キューへのアクセスを制御する認証およびアクセス制御メカニズムを提供します。

Simple Authentication and Security Layer (SASL) は、インターネットプロトコルにおける認証およびデータセキュリティーのフレームワークです。RabbitMQ と Qpid はどちらも、簡単なユーザー名とパスワードより優れた SASL およびその他のプラグ可能な認証メカニズムを提供し、認証セキュリティーが強化されます。RabbitMQ は SASL をサポートしますが、現在 OpenStack のサポートでは、特定の SASL 認証メカニズムを要求することは許可されません。OpenStack の RabbitMQ サポートでは、暗号化されていない接続を使用したユーザー名およびパスワード認証、またはユーザー名/パスワードとセキュアな TLS 接続を確立するための X.509 クライアント証明書の組み合わせのどちらか可能です。

メッセージングキューへのクライアント接続用に、すべての OpenStack サービスノードで X.509 クライアント証明書を設定することを検討してください。また、可能であれば X.509 クライアント証明書を使用した認証を実施します (現在は Qpid のみ)。ユーザー名とパスワードを使用する場合は、キューへのアクセスをより細かく監査できるように、サービスおよびノードごとにアカウントを作成する必要があります。

デプロイメントの前に、キューサーバーが使用する TLS ライブラリーを考慮してください。Qpid は Mozilla の NSS ライブラリーを使用しますが、RabbitMQ は OpenSSL を使用する Erlang の TLS モジュールを使用します。

17.3. RabbitMQ 用 OpenStack サービスの設定

本項では、OpenStack サービス用の標準的な RabbitMQ 設定について説明します。

[DEFAULT]
rpc_backend = nova.openstack.common.rpc.impl_kombu
rabbit_use_ssl = True
rabbit_host = RABBIT_HOST
rabbit_port = 5671
rabbit_user = compute01
rabbit_password = RABBIT_PASS
kombu_ssl_keyfile = /etc/ssl/node-key.pem
kombu_ssl_certfile = /etc/ssl/node-cert.pem
kombu_ssl_ca_certs = /etc/ssl/cacert.pem
注記

RABBIT_PASS を適切なパスワードに置き換えます。

17.4. Qpid 用 OpenStack サービスの設定

本項では、OpenStack サービス用の標準的な Qpid 設定について説明します。

[DEFAULT]
rpc_backend = nova.openstack.common.rpc.impl_qpid
qpid_protocol = ssl
qpid_hostname = <IP or hostname of management network interface of messaging server>
qpid_port = 5671
qpid_username = compute01
qpid_password = QPID_PASS
注記

QPID_PASS を適切なパスワードに置き換えます。

(オプション) Qpid で SASL を使用している場合は、以下を追加して、使用する SASL メカニズムを指定します。

qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>

17.5. メッセージキュープロセスの分離およびポリシー

各プロジェクトは、メッセージを送信および消費するサービスを多数提供します。メッセージを送信する各バイナリーは、返信のみの場合、キューからのメッセージを消費します。

メッセージキューサービスのプロセスは、互いに、およびマシン上の他のプロセスから分離する必要があります。

17.6. 名前空間

Linux では、名前空間を使用してプロセスを独立したドメインに割り当てます。本ガイドのその他の部分では、システムの区分について詳細に説明します。

第18章 Red Hat OpenStack Platform でのエンドポイントの保護

OpenStack クラウドと連携するプロセスは、API エンドポイントをクエリーすることで開始します。パブリックおよびプライベートのエンドポイントにはさまざまな課題がありますが、危険にさらされた場合に重大なリスクが生じる可能性のある価値の高いアセットがあります。

本章では、パブリックおよびプライベート向け API エンドポイント両方のセキュリティーを強化することを推奨しています。

18.1. 内部 API 通信

OpenStack は、パブリック向け内部管理エンドポイントとプライベート API エンドポイントの両方を提供します。デフォルトでは、OpenStack コンポーネントはパブリック向けに定義されたエンドポイントを使用します。適切なセキュリティードメイン内の API エンドポイントを使用するようにこれらのコンポーネントを設定することが推奨されます。内部管理エンドポイントにより keystone へのアクセスをさらに昇格できるため、これをさらに分離することが望ましい場合があります。

サービスは、OpenStack サービスカタログに基づいてそれぞれの API エンドポイントを選択します。これらのサービスは、リスト表示されるパブリックまたは内部 API エンドポイントの値に準拠していない可能性があります。これにより、内部管理トラフィックが外部 API エンドポイントにルーティングされる可能性があります。

18.2. Identity サービスカタログでの内部 URL の設定

Identity サービスカタログは内部 URL を認識している必要があります。この機能はデフォルトでは使用されていませんが、設定を介して利用できます。さらに、この動作がデフォルトになると、予想される変更と前方互換性があるはずです。

異なるアクセスレベルがある場合に、設定したエンドポイントをネットワークレベルから分離することを検討します。管理エンドポイントは、クラウド管理者によるアクセスを目的としています。内部またはパブリックエンドポイントでは利用できない keystone 操作へのアクセスを昇格できるためです。内部エンドポイントは、クラウド内部 (例: OpenStack サービス) の使用を目的としており、通常はデプロイメントネットワーク外からはアクセスできません。パブリックエンドポイントは TLS 対応の必要があり、クラウドユーザーが操作するデプロイメント外からアクセスできる唯一の API エンドポイントです。

エンドポイントの内部 URL の登録は、director により自動化されます。詳細は、https://github.com/openstack/tripleo-heat-templates/blob/a7857d6dfcc875eb2bc611dd9334104c18fe8ac6/network/endpoints/build_endpoint_map.py を参照してください。

18.3. 内部 URL のアプリケーションの設定

特定の API エンドポイントを使用するように一部のサービスを強制することができます。したがって、別のサービスの API に接続する OpenStack サービスは、適切な内部 API エンドポイントにアクセスするように明示的に設定する必要があります。

各プロジェクトには、ターゲット API エンドポイントを定義する方法に一貫性がなくなる場合があります。OpenStack の今後のリリースでは、Identity サービスカタログの一貫した使用でこの不整合を解決します。

18.4. Paste およびミドルウェア

OpenStack の API エンドポイントおよびその他の HTTP サービスの多くは、Python Paste Deploy ライブラリーを使用します。このライブラリーは、セキュリティーの観点からは、アプリケーションの設定を介して要求フィルターパイプラインの操作を可能にします。このチェーンの各要素はミドルウェアを指します。パイプラインでフィルターの順序を変更したり、追加のミドルウェアを追加したりすると、予測不可能なセキュリティー上の影響を及ぼす可能性があります。

一般的に、実装者は OpenStack のベース機能を拡張するためにミドルウェアを追加します。標準以外のソフトウェアコンポーネントを HTTP 要求パイプラインに追加することによって導入される潜在的な漏えいを慎重に考慮することを検討します。

18.5. API エンドポイントプロセスの分離およびポリシー

API エンドポイントプロセスを分離して、セキュリティーを高めることができます。公開されたセキュリティードメイン内の API エンドポイントを別のホストにデプロイし、隔離性を高めることを検討してください。

18.5.1. metadef API を制限するためのポリシーの設定

Red Hat OpenStack Platform (RHOSP) では、ユーザーはメタデータ定義 (metadef) API を使用してキー/値のペアおよびタグメタデータを定義することができます。現時点では、ユーザーが作成することのできる metadef 名前空間、オブジェクト、属性、リソース、またはタグの数に制限はありません。

metadef API により、情報が権限のないユーザーに漏えいする可能性があります。悪意のあるユーザーは制約がないことを悪用し、Image サービス (glance) のデータベースを無制限のリソースで埋め尽くすことができます。これにより、サービス拒否 (DoS) 型の攻撃を行うことができます。

Image サービスのポリシーは metadef API を制御します。ただし、metadef API のデフォルトのポリシー設定では、すべてのユーザーが metadef 情報を作成または読み取ることができます。metadef リソースへのアクセスは所有者だけに制限されている訳ではないため、内部インフラストラクチャーの詳細や顧客名などの秘匿すべき名前を持つ metadef リソースの情報が、悪意のあるユーザーに漏えいする可能性があります。

Image サービス (glance) をよりセキュアにするには、Red Hat OpenStack Platform (RHOSP) デプロイメントのデフォルトでは metadef 変更 API へのアクセスを管理者だけに制限します。

手順

  1. クラウド管理者として新たな heat テンプレートの環境ファイルを作成し (例: lock-down-glance-metadef-api.yaml)、Image サービス metadef API のポリシーオーバーライドを含めます。

    ...
    parameter_defaults:
      GlanceApiPolicies: {
            glance-metadef_default: { key: 'metadef_default', value: '' },
            glance-metadef_admin: { key: 'metadef_admin', value: 'role:admin' },
            glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
            glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
            glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_admin' },
            glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_admin' },
            glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_admin' },
            glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
            glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
            glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_admin' },
            glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_admin' },
            glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_admin' },
            glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
            glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
            glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_admin' },
            glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_admin' },
            glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
            glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
            glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_admin' },
            glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_admin' },
            glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_admin' },
            glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
            glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
            glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_admin' },
            glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_admin' },
            glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_admin' },
            glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_admin' },
            glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_admin' }
      }
    
    …
  2. オーバークラウドのデプロイ時に -e オプションを使用して、ポリシーオーバーライドが含まれる環境ファイルをデプロイメントコマンドに追加します。

    $ openstack overcloud deploy -e lock-down-glance-metadef-api.yaml

18.5.2. metadef API の有効化

以前にメタデータ定義 (metadef) API を制限している場合や、新規のデフォルトを緩和する場合は、metadef 変更ポリシーをオーバーライドして、ユーザーがそれぞれのリソースを更新できるようにすることが可能です。

重要

metadef API への書き込みアクセスに依存するユーザーを管理するクラウド管理者は、すべてのユーザーがこれらの API にアクセスできるようにすることが可能です。ただし、この種の設定では、顧客名や内部プロジェクト等の秘匿すべきリソース名が意図せず漏えいする可能性があります。すべてのユーザーに読み取りアクセスしか付与していない場合であっても、管理者はシステムを監査し、過去に作成したセキュリティー的に脆弱なリソースを識別する必要があります。

手順

  1. クラウド管理者としてアンダークラウドにログインし、ポリシーオーバーライド用のファイルを作成します。以下に例を示します。

    $ cat open-up-glance-api-metadef.yaml
  2. すべてのユーザーが metadef API を読み取り/書き込みできるように、ポリシーオーバーライドファイルを設定します。

    GlanceApiPolicies: {
        glance-metadef_default: { key: 'metadef_default', value: '' },
        glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
        glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_default' },
        glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_default' },
        glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
        glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
        glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_default' },
        glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_default' },
        glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_default' },
        glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
        glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
        glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
        glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_default' },
        glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_default' },
        glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
        glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
        glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_default' },
        glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_default' },
        glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_default' }
      }
    注記

    すべての metadef ポリシーを設定する際に、rule:metadeta_default を使用する必要があります。

  3. オーバークラウドのデプロイ時に -e オプションを使用して、デプロイメントコマンドに新しいポリシーファイルを追加します。

    $ openstack overcloud deploy -e open-up-glance-api-metadef.yaml

18.6. HAProxy の SSL/TLS の暗号およびルールの変更

オーバークラウドで SSL/TLS を有効にした場合は、HAProxy 設定で使用される SSL/TLS 暗号とルールを強化することを検討してください。SSL/TLS 暗号を強化することで、POODLE 脆弱性 などの SSL/TLS 脆弱性を回避できます。

  1. tls-ciphers.yaml という名前の Heat テンプレート環境ファイルを作成します。

    touch ~/templates/tls-ciphers.yaml
  2. 環境ファイルで ExtraConfig フックを使用して、値を tripleo::haproxy::ssl_cipher_suite および tripleo::haproxy::ssl_options hieradata に適用します。

    parameter_defaults:
      ExtraConfig:
        tripleo::haproxy::ssl_cipher_suite: 'DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305'
    
        tripleo::haproxy::ssl_options: 'no-sslv3 no-tls-tickets'
    注記

    暗号のコレクションは、改行せずに 1 行に記述します。

  3. オーバークラウドをデプロイする際に、overcloud deploy コマンドで tls-ciphers.yaml 環境ファイルを含めます。

    openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/tls-ciphers.yaml
    ...

18.7. ネットワークポリシー

API エンドポイントは通常複数のセキュリティーゾーンにまたがるので、API プロセスの分離に特に注意を払う必要があります。たとえば、ネットワーク設計レベルでは、指定したシステムにのみアクセスを限定することを検討してください。詳細は、セキュリティーゾーンに関するガイダンスを参照してください。

慎重にモデル化することで、ネットワーク ACL および IDS テクノロジーを使用して、ネットワークサービス間の明示的なポイントツーポイント通信を適用することができます。重要なクロスドメインサービスとして、このタイプの明示的な適用が OpenStack のメッセージキューサービスで機能します。

ポリシーを適用するには、サービス、ホストベースのファイアウォール (iptables など)、ローカルポリシー (SELinux)、およびオプションでグローバルネットワークポリシーを設定できます。

18.8. 必須のアクセス制御

API エンドポイントプロセスは、互いに、およびマシン上の他のプロセスから分離する必要があります。これらのプロセスの設定は、Discretionary Access Controls (DAC) および Mandatory Access Controls (MAC) によってこれらのプロセスに制限される必要があります。これらの強化されたアクセス制御の目的は、API エンドポイントセキュリティー違反の封じ込めを支援することにあります。

18.9. API エンドポイントのレート制限

レート制限は、ネットワークベースのアプリケーションによって受信されるイベントの頻度を制御する手段です。堅牢なレート制限が存在しない場合、アプリケーションはさまざまなサービス拒否攻撃を受けやすくなる場合があります。これは特に、その性質上、同様の要求タイプや操作を高い頻度で受け入れるように設計されている API が該当します。

すべてのエンドポイント (特にパブリック) には、物理ネットワーク設計、レート制限プロキシー、または Web アプリケーションのファイアウォールを使用するなど、追加の保護レイヤーを設定することが推奨されます。

レート制限機能を設定して実装する際に、運用者は OpenStack クラウド内のユーザーとサービスの個々のパフォーマンスニーズについて慎重に計画して考慮することが重要です。

注記: Red Hat OpenStack Platform デプロイメントの場合、全サービスは負荷分散プロキシーの背後に置かれます。

第19章 フェデレーションの実装

警告

現時点では、Red Hat はフェデレーションをサポートしていません。これはテスト目的にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。

19.1. Red Hat Single Sign-On を使用した IdM でのフェデレーション

Red Hat Single Sign-On (RH-SSO) を使用して、OpenStack 認証 (authN) 用の IdM ユーザーをフェデレーションすることができます。フェデレーションにより、IdM ユーザーは OpenStack サービスに認証情報を公開せずに OpenStack Dashboard にログインすることができます。代わりに、Dashboard がユーザーの認証情報が必要な場合には、ユーザーを Red Hat Single Sign-On (RH-SSO) に転送し、そこで IdM 認証情報を入力できるようにします。これにより、RH-SSO はユーザーが正常に認証されたとして Dashboard に戻し、Dashboard はユーザーがプロジェクトにアクセスするのを許可します。

19.2. フェデレーションのワークフロー

ここでは、Identity サービス (keystone)、RH-SSO、IdM の相互作用について説明します。OpenStack におけるフェデレーションは、認証プロバイダーとサービスプロバイダーの概念を使用します。

認証プロバイダー (IdP): ユーザーアカウントを保存するサービス。この場合、IdM に保持されるユーザーアカウントは、RH-SSO を使用して keystone に表示されます。

サービスプロバイダー (SP): IdP のユーザーからの認証を必要とするサービス。この場合、keystone は IdM ユーザーに Dashboard へのアクセスを付与するサービスプロバイダーです。

以下の図では、keystone (SP) は RH-SSO (IdP) と通信します。これは、他の IdP の汎用アダプターとしても機能することができます。この設定では、RH-SSO に keystone をポイントすることができ、RH-SSO は要求をサポートする認証プロバイダー (認証モジュールと呼ばれます) に転送します。現在、これらには IdM および Active Directory が含まれます。これは、サービスプロバイダー (SP) および認証プロバイダー (IdP) がメタデータを交換し、各システム管理者が信頼する決定を行うことで行われます。その結果、IdP は確実に決定を行い、SP はこれらの決定を受け取ることができます。

フェデレーション rhsso idm

詳細は、フェデレーションガイド (https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.2/html-single/federate_with_identity_service/) を参照してください。

法律上の通知

Copyright © 2017 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.
OpenStack Security Guide から採用された部分。ドキュメントについては、Red Hat OpenStack Platform Licenses のセキュリティーガイドを参照してください。
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, 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 Software Collections 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.