第2章 ロールの管理
2.1. ロールの管理
OpenStack はロールベースアクセス制御 (RBAC) のメカニズムを使用して、リソースへのアクセスを管理します。ロールは、ユーザーが実行可能なアクションを定義します。デフォルトでは、テナントにアタッチされるメンバーロールと、管理者以外のユーザーが環境を管理できるようにする管理者ロールという事前定義済みのロールが 2 つあります。パーミッションには抽象レベルがあり、管理者が必要なロールを作成して適切にサービスを設定することができる点に注意してください。
2.1.1. ロールの表示
利用可能な事前定義済みのロールを一覧表示するには、以下のコマンドを使用します。
$ 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 | +-----------+----------------------------------+
2.1.2. ロールの作成および割り当て
クラウド管理者は、以下のコマンド一式を使用して Keystone クライアントでロールを作成、管理できます。各 OpenStack のデプロイメントには、最低でもプロジェクト、ユーザー、ロールが 1 つずつ必要で、それぞれ連携されている必要があります。ただし、ユーザーは複数のプロジェクトのメンバーになることができます。複数のプロジェクトにユーザーを割り当てるには、ロールを作成して、ユーザーとプロジェクトのペアにそのロールを割り当てます。Dashboard でユーザーを作成して、主プロジェクトとデフォルトのロールを割り当てることができる点に注意してください。
ユーザー、ロール、プロジェクトの指定には名前または ID を使用することができます。
new-roleという名前のロールを作成します。$ openstack role create [ROLE_NAME]
例
$ openstack role create new-role +-----------+----------------------------------+ | Field | Value | +-----------+----------------------------------+ | domain_id | None | | id | 880c116b6a55464b99ca8d8d8fe26743 | | name | new-role | +-----------+----------------------------------+
ユーザーをプロジェクトに割り当てるには、ロールをユーザーとプロジェクトのペアに割り当てる必要があります。これには、ユーザー、ロール、プロジェクト名/ID を取得してください。
ユーザーを一覧表示します。
$ openstack user list
ロールを一覧表示します。
$ openstack role list
プロジェクトを一覧表示します。
$ openstack project list
ユーザーとプロジェクトのペアにロールを割り当てます。
openstack role add --project [PROJECT_NAME] --user [USER_ID] [ROLE_ID]
例
以下の例では、
demoプロジェクトでadminロールをadminユーザーに割り当てます。$ openstack role add --project demo --user 895e43465b9643b9aa29df0073572bb2 ae49e2b796ea4820ac51637be27650d8
adminユーザーのロール割り当てを確認します。$ openstack role assignment list --user [USER_ID] --project [PROJECT_ID]
例
$ openstack role assignment list --user 895e43465b9643b9aa29df0073572bb2 --project demo +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | Role | User | Group | Project | Domain | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | ae49e2b796ea4820ac51637be27650d8 | 895e43465b9643b9aa29df0073572bb2 | | 7efbdc8b4ab448b8b5aeb9fa5898ce23 | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
2.2. 暗黙的なロールとドメイン固有のロール
2.2.1. 暗黙的なロール
OpenStack では、ユーザーが特定のロールに割り当てられているのを確認して、アクセス制御を適用します。最近までは、そのようなロールはユーザーまたはユーザーがメンバーとなっているグループに明示的に割り当てられていましたが、Identity サービス (keystone) に暗黙的なロールの割り当ての概念が追加されたので、ユーザーが 1 つのロールに明示的に割り当てられている場合には、別のロールにも暗黙的に割り当てられている可能性があります。
2.2.2. 推論規則
暗黙的な割り当てはロールの推論規則で管理されます。推論規則は、上位が下位を暗黙に示す 形式で書かれます。たとえば、1 つのルールで admin ロールは _member_ ロールを暗黙的に割り当てるように記述することができます。その結果、プロジェクトの admin に割り当てられたユーザーは、_member_ ロールにも暗黙的に割り当てられます。
暗黙的なロール では、ユーザーのロール割り当ては累積的に処理され、ユーザーは下位のロールを継承することができます。暗黙的なロールは、その結果を指定するために作成される推論規則によって異なります。
2.2.2.1. Keystone の設定
keystone が暗黙的なルールを順守するには、/etc/keystone/keystone.conf で infer_roles の設定を有効にする必要があります。
[token] infer_roles = true
暗黙的なロールは、一連の定義済み推論規則によって統制されます。これらのルールにより、1 つのロールを割り当てることによって、他のロールのメンバーシップをどのように暗黙的に割り当てられることができるかを決定します。「暗黙的なロールの実例」に記載の例を参照してください。
2.2.3. 特定のロールが暗黙的となるのを防ぐ方法
特定のロールがユーザーに暗黙的に割り当てられるのを防ぐことが可能です。たとえば、/etc/keystone/keystone.conf でロールの ListOpt を追加することができます。
[assignment] prohibited_implied_role = admin
この設定は、特定のロールがユーザーに暗黙的に割り当てられるのを常に防ぎます。そのロールに対するアクセス権は、暗黙的ではなく明示的に付与しなければならないようになります。
2.2.3.1. 暗黙的なロールの実例
本項では、ロールを暗黙的に割り当てるための推論規則の作成方法について説明します。このルールは、1 つのロールが別のロールのメンバーシップを暗黙的に継承できるようにする方法を制御します。 以下の手順で使用するルールの例は、admin ロールのメンバーに _member_ のアクセスも付与されるようにします。
2.2.3.1.1. ユーザーへのロールの割り当て:
_member_ロールを暗黙的に継承するユーザーの ID を取得します。以下に例を示します。$ openstack user show User1 +---------------------+----------------------------------+ | Field | Value | +---------------------+----------------------------------+ | domain_id | default | | enabled | True | | id | ce803dd127c9489199c89ce3b68d39b4 | | name | User1 | | options | {} | | password_expires_at | None | +---------------------+----------------------------------+demoプロジェクトの ID を取得します。$ openstack project show demo +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | default tenant | | domain_id | default | | enabled | True | | id | 2717ebc905e449b5975449c370edac69 | | is_domain | False | | name | demo | | parent_id | default | +-------------+----------------------------------+
adminロールの ID を取得します。$ openstack role show admin +-----------+----------------------------------+ | Field | Value | +-----------+----------------------------------+ | domain_id | None | | id | 9b821b2920544be7a4d8f71fa99fcd35 | | name | admin | +-----------+----------------------------------+
User1ユーザーに、demoプロジェクトに対するadmin権限を付与します。$ openstack role add --user User1 --project demo admin
adminロールの割り当てを確認します。$ openstack role assignment list --user User1 --project demo --effective +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | Role | User | Group | Project | Domain | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | 9b821b2920544be7a4d8f71fa99fcd35 | ce803dd127c9489199c89ce3b68d39b4 | | 2717ebc905e449b5975449c370edac69 | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
2.2.3.1.2. 推論規則の作成
admin ロールを User1 に付与するステップが完了したので、次に以下のステップに従って推論規則を作成します。
最初に User 1 の現在のロールメンバーシップを確認します。
$ openstack role assignment list --user User1 --project demo --effective +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | Role | User | Group | Project | Domain | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | 9b821b2920544be7a4d8f71fa99fcd35 | ce803dd127c9489199c89ce3b68d39b4 | | 2717ebc905e449b5975449c370edac69 | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
ロール ID の一覧を取得します。
$ openstack role list +----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 9b821b2920544be7a4d8f71fa99fcd35 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | ea199fe4293745719c2afd3402ed7b95 | ResellerAdmin | | fe8eba5dfd1e4f4a854ad20a150d995e | SwiftOperator | +----------------------------------+---------------+
推論規則を作成します。現在このロールは
curlで作成します。この例では、前のステップで返されたロールの ID を使用します。また、keystone.conf のadmin_tokenを使用してコマンドを実行します。source overcloudrc export OS_TOKEN=`grep ^admin_token /etc/keystone/keystone.conf | awk -F'=' '{print $2}'` curl -X PUT -H "X-Auth-Token: $OS_TOKEN" -H "Content-type: application/json" $OS_AUTH_URL/roles/9b821b2920544be7a4d8f71fa99fcd35/implies/9fe2ff9ee4384b1894a90878d3e92babCLI を使用して結果を確認します。この例では、
9fe2ff9ee4384b1894a90878d3e92babの ID で示されている_member_ロールへの暗黙的なアクセスが User1 に付与されています。source overcloudrc # openstack role assignment list --user User1 --project demo --effective +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | Role | User | Group | Project | Domain | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | 9b821b2920544be7a4d8f71fa99fcd35 | ce803dd127c9489199c89ce3b68d39b4 | | 2717ebc905e449b5975449c370edac69 | | False | | 9fe2ff9ee4384b1894a90878d3e92bab | ce803dd127c9489199c89ce3b68d39b4 | | 2717ebc905e449b5975449c370edac69 | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
curl を使用して推論規則を確認します。
source overcloudrc export OS_TOKEN=`grep ^admin_token /etc/keystone/keystone.conf | awk -F'=' '{print $2}'` curl -s -H "X-Auth-Token: $OS_TOKEN" $OS_AUTH_URL/role_inferences | python -mjson.tool { "role_inferences": [ { "implies": [ { "id": "9fe2ff9ee4384b1894a90878d3e92bab", "links": { "self": "https://osp.lab.local:5000/v3/roles/9fe2ff9ee4384b1894a90878d3e92bab" }, "name": "_member_" } ], "prior_role": { "id": "9b821b2920544be7a4d8f71fa99fcd35", "links": { "self": "https://osp.lab.local:5000/v3/roles/9b821b2920544be7a4d8f71fa99fcd35" }, "name": "admin" } } ] }
2.2.4. ドメイン固有のロール
ドメイン固有のロールを使用すると、ロールのルールを定義する際に、より粒度の高い制御が可能となるので、ロールが既存の prior ロールのエイリアスとして機能することができます。ドメイン固有のロールを暗黙的に継承するグローバルロールを設定することはできない点に注意してください。このため、1 つのプロジェクト内のユーザーの有効なロールの割り当てを一覧表示しても、ドメイン固有のロールはありません。
ドメイン固有のロールを作成できるのは、keystone ドメインを管理するユーザーです。このユーザーは、OpenStack のデプロイメントの管理者である必要はありません。このため、ドメイン固有のロールの定義は特定のドメインに限定することが可能です。
ドメイン固有のロールは、トークンのスコープには使用できません。これはグローバルロールでのみ行うことができます。
2.2.4.1. ドメイン固有のロールの使用
この例では、ドメイン固有のロールを作成して、その効果を確認する方法を説明します。
ドメインを作成します。
$ openstack domain create corp01
ドメインを指定するロールを作成します (このパラメーターは
--domainとは異なる点に注意してください)。$ openstack role create operators --role-domain domain-corp01

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.