Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

2.3. Identity サービスの設定

以下のステップでは、IdM との統合に備えて、Identity サービスの準備を行います。

注記

director を使用している場合には、以下で参照されている設定ファイルが Puppet によって管理されている点に注意してください。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。これらの設定を director ベースのデプロイメントに適用するには、4章director でのドメイン固有の LDAP バックエンドの使用を参照してください。

2.3.1. コントローラーの設定

注記

設定ファイルを更新する場合には、特定の OpenStack サービスはコンテナー内で実行されるようになったことを認識する必要があります。これは、keystone、nova、cinder などのサービスが対象です。そのため、考慮すべき特定の管理プラクティスがいくつかあります。

  • 物理ノードのホストオペレーティングシステム上の設定ファイル (例: /etc/cinder/cinder.conf) は更新しないでください。コンテナー化されたサービスはこのようなファイルを参照しません。

  • コンテナー内で実行されている設定ファイルは更新しないでください。コンテナーを再起動すると変更が失われてしまいます。

    代わりに、コンテナー化されたサービスに変更を加える必要がある場合は、コンテナーの生成に使用される設定ファイルを更新する必要があります。これらのファイルは /var/lib/config-data/puppet-generated/ 内に保管されています。

    以下に例を示します。

  • keystone: /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf
  • cinder: /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

  • nova: /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf

    変更内容は、コンテナーを再起動した後に適用されます。例: sudo docker restart keystone

keystone サービスを実行しているコントローラーで、以下の手順を実行します。

  1. SELinux を設定します。 

    # setsebool -P authlogin_nsswitch_use_ldap=on

    出力には、以下のようなメッセージが含まれている場合がありますが、これは無視できます。 

    Full path required for exclude: net:[4026532245].

  2. domains ディレクトリーを作成します。 

    # mkdir /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
# chown 42425:42425 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/

  3. Identity サービスが複数のバックエンドを使用するように設定します。

    注記

    yum install crudini のコマンドを実行して crudini をインストールする必要がある場合があります。 

    # crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf assignment driver sql
    注記

    director を使用している場合には、/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf が Puppet によって管理されている点に注意してください。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。director ベースのデプロイメントについては、4章director でのドメイン固有の LDAP バックエンドの使用を参照してください。

  4. Dashboard で複数のドメインを有効にします。以下の行を /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings に追加します。 

    OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'
    注記

    director を使用している場合には、/var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings が Puppet によって管理されている点に注意してください。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。

    horizon コンテナーを再起動して、設定を適用します。 

    $ sudo docker restart horizon

  5. 追加のバックエンドを設定します。

    1. IdM 統合のための keystone ドメインを作成します。新規 keystone ドメインに使用する名前を決定してから、ドメインを作成する必要があります。たとえば、以下のコマンドは LAB という名前の keystone ドメインを作成します。 

      $ openstack domain create LAB

    2. 設定ファイルを作成します。

      IdM バックエンドを追加するには、/var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf (LAB は、前のステップで作成したドメイン名に置き換えます) という名前の新規ファイルに LDAP 設定を入力します。以下の設定例は、実際に使用する IdM デプロイメントに合わせて編集する必要があります。 

      [ldap]
url =  ldaps://idm.lab.local
user = uid=svc-ldap,cn=users,cn=accounts,dc=lab,dc=local
user_filter = (memberOf=cn=grp-openstack,cn=groups,cn=accounts,dc=lab,dc=local)
password = RedactedComplexPassword
user_tree_dn = cn=users,cn=accounts,dc=lab,dc=local
user_objectclass = inetUser
user_id_attribute = uid
user_name_attribute = uid
user_mail_attribute = mail
user_pass_attribute =
group_tree_dn               = cn=groups,cn=accounts,dc=lab,dc=local
group_objectclass              = groupOfNames
group_id_attribute            = cn
group_name_attribute       =  cn
group_member_attribute  = member
group_desc_attribute        = description
use_tls                  = False
query_scope                  = sub
chase_referrals                  = false
tls_cacertfile =/etc/pki/ca-trust/source/anchors/anchorsca.crt

[identity]
driver = ldap

      各設定項目について説明します。

      設定説明

      url

      認証に使用する IdM サーバー。LDAPS ポート 636 を使用します。

      user

      LDAP クエリーに使用する IdM 内のアカウント。

      password

      上記で使用した IdM アカウントのパスワード (プレーンテキスト形式)。

      user_filter

      Identity サービスに対して提示するユーザーをフィルターリングします。その結果、grp-openstack グループのメンバーのみに Identity サービスで定義されているパーミッションを付与することができます。

      user_tree_dn

      IdM 内の OpenStack アカウントへのパス。

      user_objectclass

      LDAP ユーザーの種別を定義します。IdM には inetUser の種別を使用します。

      user_id_attribute

      ユーザー ID に使用する IdM 値をマッピングします。

      user_name_attribute

      names に使用する IdM 値をマッピングします。

      user_mail_attribute

      ユーザーのメールアドレスに使用する IdM 値をマッピングします。

      user_pass_attribute

      この値は空白のままにします。

      注記

      IdM グループとの統合で返されるのは直接のメンバーだけで、ネスト化されたグループは返されません。したがって、LDAP_MATCHING_RULE_IN_CHAIN または memberof:1.2.840.113556.1.4.1941: に依存するクエリーは、現在 IdM では機能しません。

  6. 設定ファイルの所有者を keystone ユーザーに変更します。 

    # chown 42425:42425 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf

  7. admin ユーザーにドメインへのアクセス権を付与します。

    注記

    この手順を実行しても、OpenStack admin アカウントには IdM のパーミッションは付与されません。ここで使われるドメインという用語は、OpenStack が使用する keystone ドメインのことを指しています。

    1. LAB ドメインの ID を取得します。 

      $ openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+

    2. admin ユーザーの ID の値を取得します。 

      $ openstack user list --domain default | grep admin

| 3d75388d351846c6a880e53b2508172a | admin      |

    3. admin ロールの ID の値を取得します。 

      # openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

    4. 返されたドメインおよび admin の ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。 

      $ openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf

  8. keystone サービスを再起動して、変更を適用します。 

    $ sudo docker restart keystone

  9. コマンドで keystone ドメイン名を指定して、IdM ドメイン内のユーザー一覧を確認します。 

    $ openstack user list --domain LAB

  10. ローカルの keystone データベース内のサービスアカウントを確認します。 

    $ openstack user list --domain default

2.3.2. IdM グループのメンバーによるプロジェクトへのアクセスの許可

認証されたユーザーが OpenStack リソースにアクセスするのを許可するための推奨される方法は、特定の IdM グループを承認してプロジェクトへのアクセス権を付与することです。これにより、OpenStack の管理者は、プロジェクト内で各ユーザーをロールに割り当てる必要がなくなります。代わりに、IdM グループにプロジェクト内のロールが付与されます。その結果、これらの IdM グループのメンバーである IdM ユーザーは、事前定義済みのプロジェクトにアクセスできるようになります。

注記

個々の IdM ユーザーの承認プロセスを手動で管理する方が望ましい場合には、「IdM ユーザーによるプロジェクトへのアクセスの許可」を参照してください。

本項は、IdM の管理者が以下のステップをすでに完了していることを前提としています。

  • IdM で grp-openstack-admin という名前のグループを作成する。
  • IdM で grp-openstack-demo という名前のグループを作成する。
  • 必要に応じて、上記のグループの 1 つに IdM ユーザーを追加する。
  • IdM ユーザーを grp-openstack グループに追加する。
  • 目的のプロジェクトを作成する。以下の例では、openstack project create --domain default --description "Demo Project" demo を使用して作成した demo という名前のプロジェクトを使用します。

以下のステップでは、IdM グループにロールを割り当てます。これで、グループのメンバーに OpenStack リソースへのアクセス権が付与されます。

  1. IdM グループの一覧を取得します。 

    $ openstack group list --domain LAB
+------------------------------------------------------------------+---------------------+
| ID                                                               | Name                |
+------------------------------------------------------------------+---------------------+
| 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack       |
| a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin |
| d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo  |
+------------------------------------------------------------------+---------------------+

  2. ロールの一覧を取得します。 

    $ openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin |
| 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
| d3570730eb4b4780a7fed97eba197e1b | SwiftOperator |
+----------------------------------+---------------+

  3. IdM グループに上記のロールを 1 つまたは複数追加して、プロジェクトへのアクセス権を付与します。たとえば、grp-openstack-demo グループ内のユーザーを demo プロジェクトの一般ユーザーにするには、そのグループを _member_ ロールに追加する必要があります。 

    $ openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8  _member_

その結果、grp-openstack-demo のメンバーは、IdM のユーザー名とパスワードを入力してから、ドメインフィールドにも LAB と入力すると Dashboard にログインすることができます。

domain
注記

ユーザーに Error: Unable to retrieve container list. というエラーメッセージが表示され、コンテナーの管理が可能であることが想定されている場合には、SwiftOperator ロールに追加する必要があります。

2.3.3. IdM ユーザーによるプロジェクトへのアクセスの許可

grp-openstack IdM グループのメンバーである IdM ユーザーには、Dashboard 内の プロジェクト にログインするパーミッションを付与することができます。

  1. IdM ユーザーの一覧を取得します。 

    # openstack user list --domain LAB
 +------------------------------------------------------------------+----------------+
| ID                                                               | Name           |
+------------------------------------------------------------------+----------------+
| 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
| 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2          |
| afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3          |
| e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4          |
+------------------------------------------------------------------+----------------+

  2. ロールの一覧を取得します。 

    # openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

  3. 一覧表示されたロールの中から 1 つまたは複数のロールをユーザーに追加して、プロジェクトへのアクセス権を付与します。たとえば、user1 を demo プロジェクトの一般ユーザーにするには、member ロールに追加します。 

    # openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_

    または、user1 を demo プロジェクトの管理ユーザーにするには、admin ロールに追加します。 

    # openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin

    その結果、user1 は IdM のユーザー名とパスワードを入力してから、Domain のフィールドにも LAB と入力すると Dashboard にログインすることができます。

domain
注記

ユーザーに Error: Unable to retrieve container list. というエラーメッセージが表示され、コンテナーの管理が可能であることが想定されている場合には、SwiftOperator ロールに追加する必要があります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.