第5章 プロジェクト管理

5.1. プロジェクト管理

クラウド管理者は、プロジェクト (テナント) を作成、管理することができます。テナントは、OpenStack ユーザーとリソースの数が割り当てられたプロジェクトです。テナントごとにクォータを設定することができます。これにより、相互のパーミッションやリソースを干渉することなく、複数のプロジェクトが単一のクラウドを使用できるようになります。プロジェクトとテナントという用語はいずれも同じ意味で使用されます。ユーザーは、複数のプロジェクトに割り当てることができます。ユーザーとプロジェクトのペアごとに、ロールを 1 つ割り当てる必要があります。

5.1.1. プロジェクトの作成

プロジェクトの作成、プロジェクトへのメンバーの追加、プロジェクトのリソース制限の設定は、以下の手順を実行します。

  1. Dashboard に管理ユーザーとしてログインして アイデンティティー > プロジェクト を選択します。
  2. プロジェクトの作成 をクリックします。
  3. プロジェクト情報 タブでプロジェクトの名前と説明を入力します (有効 のチェックボックスはデフォルトで選択されます)。
  4. プロジェクトへのメンバーの追加は、プロジェクトメンバー タブの すべてのユーザー リストから行います。
  5. クォータ タブで、プロジェクトのリソースの上限を指定します。
  6. プロジェクトの作成 をクリックします。

5.1.2. プロジェクトの編集

プロジェクトを編集して名前や説明を変更したり、プロジェクトを有効化または一時的に無効化したり、メンバーを更新したりすることができます。

  1. Dashboard に管理ユーザーとしてログインして アイデンティティー > プロジェクト を選択します。
  2. プロジェクトの アクション コラムで、下向きの三角をクリックして プロジェクトの編集 をクリックします。
  3. プロジェクトの編集 ウィンドウでプロジェクトを更新して名前や説明を変更したり、プロジェクトを有効化または一時的に無効化したりすることができます。
  4. プロジェクトメンバー タブで、必要に応じてメンバーをプロジェクトに追加または削除します。
  5. 保存 をクリックします。
注記

有効 のチェックボックスはデフォルトで選択されています。プロジェクトを一時的に無効にするには、有効 のチェックボックスのチェックマークを外します。無効なプロジェクトを有効にするには、有効 チェックボックスを選択します。

5.1.3. プロジェクトの削除

  1. Dashboard に管理ユーザーとしてログインして アイデンティティー > プロジェクト を選択します。
  2. 削除するプロジェクトを選択します。
  3. プロジェクトの削除 をクリックします。プロジェクトの削除の確認 ウィンドウが表示されます。
  4. プロジェクトの削除 をクリックしてアクションを確認します。

プロジェクトが削除され、ユーザーとのペアリングの関連付けは解除されます。

5.1.4. プロジェクトクォータの更新

クォータとは、クラウドリソースを最適化するためにプロジェクトごとに設定可能な操作の制約のことです。クォータを設定して、通知なしにプロジェクトのリソースが使い果たされないようにします。クォータは、プロジェクトレベルとプロジェクトとユーザーレベルの両方で実行できます。

  1. Dashboard に管理ユーザーとしてログインして アイデンティティー > プロジェクト を選択します。
  2. プロジェクトの アクション コラムで、下向きの三角をクリックして クォータの変更 をクリックします。
  3. クォータ タブで、必要に応じてプロジェクトクォータを変更します。
  4. 保存 をクリックします。

5.1.5. 現在のプロジェクトの変更

ユーザーは、メンバーとなっているプロジェクトのみ、現在のプロジェクトとして設定することができます。また、現在のプロジェクトに設定 オプションを有効にするには、ユーザーが複数のプロジェクトのメンバーである必要があります。現在のプロジェクトとして設定すると、現在のプロジェクトとして指定されたプロジェクトのオブジェクトに、Dashboard からアクセスできるようになります。無効にしたプロジェクトは、有効化しない限り、現在のプロジェクトとして設定できません。

  1. Dashboard に管理ユーザーとしてログインして アイデンティティー > プロジェクト を選択します。
  2. プロジェクトの アクション コラムで、下向きの三角をクリックして 現在のプロジェクトに設定 をクリックします。
  3. または、管理者権限のないユーザーで、プロジェクトの アクション コラムの下向きの三角をクリックして 現在のプロジェクトに設定 をクリックすると、このコラムのデフォルトアクションになります。

5.2. プロジェクトの階層

5.2.1. Identity サービスの階層型マルチテナンシー (HMT)

プロジェクトは、keystone のマルチテナンシーを使用して入れ子にすることができます。マルチテナンシーにより、サブプロジェクトは親プロジェクトのロール割り当てを継承することができます。

5.2.1.1. プロジェクトとサブプロジェクトの作成

階層型マルチテナンシー (HMT) は keystone のドメインとプロジェクトを使用して実装することができます。まず最初に新規ドメインを作成して、そのドメイン内にプロジェクトを作成します。これで、そのプロジェクトにサブプロジェクトを追加できるようになります。また、ユーザーをサブプロジェクトの admin ロールに追加すると、そのサブプロジェクトの管理者に昇格することができます。

注記

keystone の使用する HMT の構造は、現在 Dashboard では表示されません。

以下に例を示します。

1. corp という名前の keystone ドメインを新規作成します。

$ openstack domain create corp
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| enabled     | True                             |
| id          | 69436408fdcb44ab9e111691f8e9216d |
| name        | corp                             |
+-------------+----------------------------------+

2.corp ドメイン内に 親プロジェクト (private-cloud) を作成します。

$ openstack project create private-cloud --domain corp
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| domain_id   | 69436408fdcb44ab9e111691f8e9216d |
| enabled     | True                             |
| id          | c50d5cf4fe2e4929b98af5abdec3fd64 |
| is_domain   | False                            |
| name        | private-cloud                    |
| parent_id   | 69436408fdcb44ab9e111691f8e9216d |
+-------------+----------------------------------+

3. private-cloud の親プロジェクト内で corp ドメインも指定して サブプロジェクト (dev) を作成します。

$ openstack project create dev --parent private-cloud --domain corp
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| domain_id   | 69436408fdcb44ab9e111691f8e9216d |
| enabled     | True                             |
| id          | 11fccd8369824baa9fc87cf01023fd87 |
| is_domain   | False                            |
| name        | dev                              |
| parent_id   | c50d5cf4fe2e4929b98af5abdec3fd64 |
+-------------+----------------------------------+

4. qa という名前のサブプロジェクトをもう 1 つ作成します。

$ openstack project create qa --parent private-cloud --domain corp
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| domain_id   | 69436408fdcb44ab9e111691f8e9216d |
| enabled     | True                             |
| id          | b4f1d6f59ddf413fa040f062a0234871 |
| is_domain   | False                            |
| name        | qa                               |
| parent_id   | c50d5cf4fe2e4929b98af5abdec3fd64 |
+-------------+----------------------------------+
注記

Identity API を使用してプロジェクトの階層を確認することができます。詳しくは、https://developer.openstack.org/api-ref/identity/v3/index.html?expanded=show-project-details-detail を参照してください。

5.2.1.2. ユーザーへのアクセス権の付与

デフォルトでは、新規作成したプロジェクトにはロールは割り当てられません。ロールのパーミッションを親プロジェクトに割り当てる時には、--inherited フラグを指定して、サブプロジェクトが親プロジェクトからパーミッションを継承するように指定することができます。たとえば、親プロジェクトに対する admin ロールのアクセス権のあるユーザーには、サブプロジェクトへの admin アクセス権も付与されます。

1. プロジェクトに割り当てられている既存のパーミッションを確認します。

$ openstack role assignment list --project private-cloud

2. 既存のロールを確認します。

$ openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 3a5137e4b620489791df1152ac013bfa | ResellerAdmin |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
| cf4f87df933b455f957cf03b6d3784d2 | admin         |
| eef5cea6ff9549aa98cccc208c370d80 | SwiftOperator |
+----------------------------------+---------------+

3. private-cloud プロジェクトに対する user1 のアクセス権をユーザーアカウントに付与します。

$ openstack role add --user user1 --user-domain corp --project private-cloud _member_

--inherited フラグを指定して上記のコマンドを再度実行すると、user1 には、ロールの割り当てから継承された private-cloud サブプロジェクトへのアクセス権も付与されます。

$ openstack role add --user user1 --user-domain corp --project private-cloud _member_ --inherited

4. パーミッションの更新の結果を確認します。

$ openstack role assignment list --effective --user user1 --user-domain corp
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| Role                             | User                             | Group | Project                          | Domain | Inherited |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| 9fe2ff9ee4384b1894a90878d3e92bab | 10b5b34df21d485ca044433818d134be |       | c50d5cf4fe2e4929b98af5abdec3fd64 |        | False     |
| 9fe2ff9ee4384b1894a90878d3e92bab | 10b5b34df21d485ca044433818d134be |       | 11fccd8369824baa9fc87cf01023fd87 |        | True      |
| 9fe2ff9ee4384b1894a90878d3e92bab | 10b5b34df21d485ca044433818d134be |       | b4f1d6f59ddf413fa040f062a0234871 |        | True      |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+

この結果では、user1qa および dev プロジェクトへのアクセス権を継承していることが確認できます。また、親プロジェクトに --inherited フラグが適用されたので、user1 は後ほど作成されるサブプロジェクトにはすべてアクセス権が自動的に付与されます。

5.2.2. アクセスの削除

明示的に割り当てられたパーミッションと継承されたパーミッションは別々に削除する必要があります。以下に例を示します。

1. 明示的に割り当てられたロールからユーザーを削除します。

$ openstack role remove --user user1 --project private-cloud _member_

2. 変更の結果を確認します。継承されたパーミッションがまだ存在している点に注意してください。

$ openstack role assignment list --effective --user user1 --user-domain corp
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| Role                             | User                             | Group | Project                          | Domain | Inherited |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| 9fe2ff9ee4384b1894a90878d3e92bab | 10b5b34df21d485ca044433818d134be |       | 11fccd8369824baa9fc87cf01023fd87 |        | True      |
| 9fe2ff9ee4384b1894a90878d3e92bab | 10b5b34df21d485ca044433818d134be |       | b4f1d6f59ddf413fa040f062a0234871 |        | True      |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+

3. 継承されたパーミッションを削除します。

$ openstack role remove --user user1 --project private-cloud _member_ --inherited

4. 変更の結果を確認します。継承されたパーミッションが削除され、出力が空になりました。

$ openstack role assignment list --effective --user user1 --user-domain corp

5.2.3. ネストされたクォータ

現時点では、ネストされたクォータ はまだサポートされていません。そのため、クォータはプロジェクトとサブプロジェクトで別々に管理する必要があります。

5.2.4. Reseller の概要

Reseller プロジェクトでは、複数のドメインを階層化することを目標としています。このようなドメインでは、1 つのサブドメインは、完全に有効化された 1 つのクラウドを表現し、最終的にはクラウドの部分的な再販を考慮することができます。この開発の作業は複数の段階に分かれています。第 1 段階については以下に説明します。

5.2.4.1. Reseller の第 1 段階

Reseller (第 1 段階) は、「Identity サービスの階層型マルチテナンシー (HMT)」に記載の階層型マルチテナンシー (HMT) の延長です。従来 keystone ドメインは、データベースバックエンド内に独自のテーブルを備えた、ユーザーとプロジェクトを保管するためのコンテナーとすることを目的としていました。その結果、ドメインは独自のテーブルには保管されなくなり、プロジェクトのテーブルにマージされました。

  • ドメインは、プロジェクトの種別の一つとなり、is_domain フラグで区別されます。
  • ドメインは、プロジェクト階層の最上位のプロジェクトを表します。ドメインは、プロジェクト階層のルートです。
  • projects サブパスを使用してドメインの作成と取得をするように API が更新されました。

    • 新規ドメインを作成するには、is_domain フラグを true に指定してプロジェクトを作成します。
    • ドメインであるプロジェクトを一覧表示します。is_domain クエリーパラメーターを含むプロジェクトを取得します。
注記

第 1 段階では、ドメインの階層を作成することはできないので、サブドメインはまだ利用できません。また、これによりトークンのスコープは変わらず、keystone 以外のプロジェクトに必要な階層のサポートは実装されません。

5.3. プロジェクトのセキュリティー管理

セキュリティーグループとは、プロジェクトのインスタンスに割り当て可能な IP フィルターのルールセットで、インスタンスへのネットワークのアクセス権限を定義します。セキュリティーグループはプロジェクト別になっており、プロジェクトメンバーは自分のセキュリティーグループのデフォルトルールを編集して新規ルールセットを追加することができます。

プロジェクトにはすべて default セキュリティーグループが存在し、他にセキュリティーグループが定義されていないインスタンスに対して適用されます。このセキュリティーグループは、デフォルト値を変更しない限り、インスタンスへの受信トラフィックをすべて拒否し、送信トラフィックのみを許可します。

5.3.1. セキュリティーグループの作成

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. セキュリティーグループ タブで、セキュリティーグループの作成 をクリックします。
  3. セキュリティーグループに名前と説明を指定して、セキュリティーグループの作成 をクリックします。

5.3.2. セキュリティーグループのルールの追加

デフォルトでは、新しいグループには、送信アクセスのルールのみが指定されます。他のアクセスを指定するには、新しいルールを追加する必要があります。

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. セキュリティーグループ タブで、編集するセキュリティーグループの ルールの管理 をクリックします。
  3. 新規ルールを追加するには、 ルールの追加 をクリックします。
  4. ルールの値を指定して、追加 をクリックします。

    以下のルールのフィールドは必須です。

    ルール

    ルールタイプ。ルールテンプレート (例: SSH) を指定する場合には 、そのフィールドは自動的に入力されます。

    • TCP: 一般的には、システム間のデータの交換や、エンドユーザーの通信に使用されます。
    • UDP: 一般的には、システム間のデータ交換に (特にアプリケーションレベルで) 使用されます。
    • ICMP: 一般的には、ルーターなどのネットワークデバイスがエラーや監視メッセージを送信するのに使用されます。
    方向
    受信 (インバウンド) または送信 (アウトバウンド)
    開放するポート

    TCP または UDP ルールでは、開放する ポート または ポート範囲 (単一のポートまたはポートの範囲) を入力します。

    • ポート範囲では、ポート番号 (下限)ポート番号 (上限) にポートの値を入力します。
    • 単一のポートの場合は ポート フィールドにポートの値を入力します。
    タイプ
    ICMP ルールのタイプ。-1:255 の範囲で指定する必要があります。
    コード
    ICMP ルールのコード。-1:255 の範囲で指定する必要があります。
    接続相手

    このルールが適用されるトラフィックの接続元

    • CIDR (Classless Inter-Domain Routing): 指定のブロック内の IP へのアクセスを制限する IP アドレスブロック。接続相手フィールドに CIDR を入力します。
    • セキュリティーグループ: グループ内のインスタンスが他のグループインスタンスにアクセスできるようにするソースのセキュリティーグループ

5.3.3. セキュリティーグループルールの削除

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. セキュリティーグループ タブで、セキュリティーグループの ルールの管理 をクリックします。
  3. セキュリティーグループルールを選択し、イメージの削除 ボタンをクリックします。
  4. 再度、ルールの削除 をクリックします。
注記

削除の操作は元に戻すことはできません。

5.3.4. セキュリティーグループの削除

  1. Dashboard で プロジェクト > コンピュート > アクセスとセキュリティー を選択します。
  2. セキュリティーグループ タブで、グループを選択して、セキュリティーグループの削除 をクリックします。
  3. セキュリティーグループの削除 をクリックします。
注記

削除の操作は元に戻すことはできません。