検索

2.8. Identity サービスの設定

download PDF

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

注記

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

2.8.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 systemctl restart tripleo_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 サービスが複数のバックエンドを使用するように設定します。

    注記

    dnf 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 systemctl restart tripleo_horizon
  5. 追加のバックエンドを設定します。

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

      $ openstack domain create LAB
      注記

      このコマンドが使用できない場合には、コマンドラインセッションでの keystone v3 へのアクセスが有効化されているかどうかを確認してください。

    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 podman restart keystone
  9. コマンドで keystone ドメイン名を指定して、IdM ドメイン内のユーザー一覧を確認します。

    $ openstack user list --domain LAB
  10. ローカルの keystone データベース内のサービスアカウントを確認します。

    $ openstack user list --domain default
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.