ユーザーおよびアイデンティティー管理ガイド

Dashboard でユーザーを作成するには、以下の手順に従ってください。主プロジェクトおよびロールをユーザーに割り当てることができます。Dashboard で作成したユーザーは、デフォルトでは Keystone のユーザーとなっています。Active Directory ユーザーを統合するには、Red Hat OpenStack Platform の Identity サービスに含まれる LDAP プロバイダーを設定してください。

主プロジェクトなど、ユーザーの詳細を更新するには、以下の手順に従います。

ユーザーを有効化または無効化するには、以下の手順に従います。1 度に 1 ユーザーしか無効化または有効化できません。無効化されたユーザーは Dashboard にはログインできず、OpenStack サービスへのアクセスもできません。また、無効化されたユーザーの主プロジェクトもアクティブに設定できません。アクションを元に戻せないユーザーの削除とは異なり、無効化されたユーザーをもう 1 度有効化することができます。また、ユーザーが無効な場合には、Dashboard のユーザーとプロジェクトのアクションを実行するには、ユーザーを有効化する必要があります。

管理ユーザーが Dashboard を使用してユーザーを削除するには、以下の手順を実行します。このアクションは、ユーザーの無効化とは異なり、元に戻すことはできません。ユーザーを無効にした場合には、所属するプロジェクトのメンバー一覧から削除されます。ユーザーとプロジェクトのペアに関連付けられたロールはすべて失われます。

利用可能な事前定義済みのロールを一覧表示するには、以下のコマンドを使用します。

$ openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 4fd37c2c993a4acab8e1b5896afb8687 | SwiftOperator |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
| a0f19c1381c54770ae068456c4411d82 | ResellerAdmin |
| ae49e2b796ea4820ac51637be27650d8 | admin         |
+----------------------------------+---------------+

指定したロールの詳細を取得するには、以下のコマンドを実行します。

$ openstack role show admin

$ openstack role show admin
+-----------+----------------------------------+
| Field     | Value                            |
+-----------+----------------------------------+
| domain_id | None                             |
| id        | ae49e2b796ea4820ac51637be27650d8 |
| name      | admin                            |
+-----------+----------------------------------+

クラウド管理者は、以下のコマンド一式を使用して Keystone クライアントでロールを作成、管理できます。各 OpenStack デプロイメントには、最低でもプロジェクト、ユーザー、ロールが 1 つずつあり、それらが連携している必要があります。ただし、ユーザーは複数のプロジェクトのメンバーになることができます。複数のプロジェクトにユーザーを割り当てるには、ロールを作成して、ユーザーとプロジェクトのペアにそのロールを割り当てます。Dashboard でユーザーを作成して、主プロジェクトとデフォルトのロールを割り当てることができる点に注意してください。

OpenStack では、ユーザーが特定のロールに割り当てられているのを確認して、アクセス制御を適用します。最近までは、そのようなロールはユーザーまたはユーザーがメンバーとなっているグループに明示的に割り当てる必要がありました。Identity サービス (keystone) に暗黙的なロール割り当ての概念が追加されたので、ユーザーが 1 つのロールに明示的に割り当てられている場合には、別のロールにも暗黙的に割り当てられている可能性があります。

暗黙的な割り当てはロールの推論規則で管理されます。推論規則は、上位が下位を暗黙に示す 形式で書かれます。たとえば、1 つのルールで admin ロールは _member_ ロールを暗黙的に割り当てるように記述することができます。その結果、プロジェクトの admin に割り当てられたユーザーは、_member_ ロールにも暗黙的に割り当てられます。

暗黙的なロール では、ユーザーのロール割り当ては累積的に処理され、ユーザーは下位のロールを継承することができます。暗黙的なロールは、その結果を指定するために作成される推論規則によって異なります。

[token]
infer_roles = true

特定のロールがユーザーに暗黙的に割り当てられるのを防ぐことが可能です。たとえば、/etc/keystone/keystone.conf でロールの ListOpt を追加することができます。

[assignment]
prohibited_implied_role = admin

この設定は、特定のロールがユーザーに暗黙的に割り当てられるのを常に防ぎます。そのロールに対するアクセス権は、暗黙的ではなく明示的に付与しなければならないようになります。

Identity サービス (keystone) グループを使用すると、一定のパーミッションを複数のユーザーアカウントに割り当てることができます。以下の例では、グループを作成して、そのグループにパーミッションを割り当てます。その結果、そのグループに割り当てられているのと同じパーミッションがグループのメンバーに継承されます。

Dashboard を使用して keystone グループのメンバーシップを管理することができます。グループへのロールパーミッションの割り当てには、上記の例で説明したようにコマンドラインを使用する必要があります。

ユーザーに現在設定されているクォータの値を一覧表示するには、以下のコマンドを実行します。

$ nova quota-show --user [USER] --tenant [TENANT]

$ nova quota-show --user demoUser --tenant demo
+-----------------------------+-------+
| Quota                       | Limit |
+-----------------------------+-------+
| instances                   | 10    |
| cores                       | 20    |
| ram                         | 51200 |
| floating_ips                | 5     |
| fixed_ips                   | -1    |
| metadata_items              | 128   |
| injected_files              | 5     |
| injected_file_content_bytes | 10240 |
| injected_file_path_bytes    | 255   |
| key_pairs                   | 100   |
| security_groups             | 10    |
| security_group_rules        | 20    |
| server_groups               | 10    |
| server_group_members        | 10    |
+-----------------------------+-------+

特定のクォータ値を更新するには、以下のコマンドを実行します。

$ nova quota-update --user [USER] --[QUOTA_NAME] [QUOTA_VALUE] [TENANT]
$ nova quota-show --user [USER] --tenant [TENANT]

$ nova quota-update --user demoUser --floating-ips 10 demo
$ nova quota-show --user demoUser --tenant demo
+-----------------------------+-------+
| Quota                       | Limit |
+-----------------------------+-------+
| instances                   | 10    |
| cores                       | 20    |
| ram                         | 51200 |
| floating_ips                | 10    |
| ...                         |       |
+-----------------------------+-------+

$ nova help quota-update

オブジェクトストレージクォータは、以下のカテゴリーに分類できます。

コンテナークォータまたはアカウントクォータのいずれかを設定するには、Object Storage プロキシーサーバーにおいて、proxy-server.conf ファイルの [pipeline:main] セクションに container_quotas または account_quotas (または両方) のパラメーターを追加する必要があります。

[pipeline:main]
pipeline = catch_errors [...] tempauth container-quotas \
account-quotas slo dlo proxy-logging proxy-server

[filter:account_quotas]
use = egg:swift#account_quotas

[filter:container_quotas]
use = egg:swift#container_quotas

オブジェクトストレージクォータの表示および更新には、以下のコマンドを使用します。プロジェクトに含まれるすべてのユーザーには、そのプロジェクトに指定されているクォータが表示されます。プロジェクトに設定されているオブジェクトストレージのクォータを更新するには、そのプロジェクトの ResellerAdmin のロールが必要です。

アカウントクォータを表示するには、以下のコマンドを実行します。

# swift stat

Account: AUTH_b36ed2d326034beba0a9dd1fb19b70f9
Containers: 0
Objects: 0
Bytes: 0
Meta Quota-Bytes: 214748364800
X-Timestamp: 1351050521.29419
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes

クォータを更新するには、以下を実行します。

# swift post -m quota-bytes:<BYTES>

たとえば、アカウントに 5 GB のクォータを指定します。

# swift post -m quota-bytes:5368709120

クォータの確認をするには swift statコマンドをもう 1 度実行します。

# swift stat

Account: AUTH_b36ed2d326034beba0a9dd1fb19b70f9
Containers: 0
Objects: 0
Bytes: 0
Meta Quota-Bytes: 5368709120
X-Timestamp: 1351541410.38328
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes

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

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

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

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

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

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

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

$ 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 |
+-------------+----------------------------------+

$ 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 |
+-------------+----------------------------------+

$ 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 |
+-------------+----------------------------------+

$ openstack role assignment list --project private-cloud

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

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

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

$ 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      |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+

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

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

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

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

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

以下のコードは、Active Directory に対してクエリーを実行して CA 証明書を取得する方法の例を示しています。CA_NAME は証明書の名前に置き換え (mmc.exe で確認可能)、その他のパラメーターは実際の設定に応じて変更することができます。

CA_NAME="WIN2012DOM-WIN2012-CA"
AD_SUFFIX="dc=win2012dom,dc=com" LDAPURL="ldap://win2012.win2012dom.com"
ADMIN_DN="cn=Administrator,cn=Users,$AD_SUFFIX"
ADMINPASSWORD="MyPassword"

CA_CERT_DN="cn=latexmath:[$CA_NAME,cn=certification authorities,cn=public key services,cn=services,cn=configuration,$]AD_SUFFIX"

TMP_CACERT=/tmp/cacert.`date +'%Y%m%d%H%M%S'`.$$.pem

ldapsearch -xLLL -H
latexmath:[$LDAPURL -D `echo \"$]ADMIN_DN"`-W -s base -b`echo
"$CA_CERT_DN"` objectclass=* cACertificate

/path/cacert.pem という名前のファイルを作成し、以下の例に示したように、Active Directory から CA 証明書を取得するための LDAP クエリーの内容をヘッダーとフッターの間に追加します。

-----BEGIN CERTIFICATE-----
MIIDbzCCAlegAwIBAgIQQD14hh1Yz7tPFLXCkKUOszANB... -----END
CERTIFICATE-----

トラブルシューティングを行う場合には、以下のクエリーを実行して LDAP が稼働しているかをチェックし、PEN 証明書ファイルが正しく作成されたことを確認してください。

LDAPTLS_CACERT=/path/cacert.pem ldapsearch -xLLL -ZZ -H $LDAPURL -s base -b "" "objectclass=*" currenttime

このクエリーによって、以下のような結果が返されるはずです。

dn: currentTime:
20141022050611.0Z

CA 証明書が Web サーバーでホストされていた場合には、以下のコマンドを実行して CA 証明書を取得することができます。

# echo Q | openssl s_client -connect $HOST:$PORT | sed -n -e '/BEGIN CERTIFICATE/,/END CERTIFICATE/ p'