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. keystone が複数のバックエンドを使用するように設定します。

   注記

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

   以下の例では、LAB は、Identity サービスドメインとして使用する NetBIOS の名前です。

   1. AD DS を統合するための keystone ドメインを作成します。

      上記のステップで取得した NetBIOS 名の値をドメイン名として使用します。このアプローチでは、ログインプロセス中に、一貫したドメイン名をユーザーに提示することができます。たとえば、NetBIOS 名が LAB の場合には、以下のコマンドを実行します。

      $ openstack domain create LAB

      注記

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

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

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

      [ldap]
      url                  = ldaps://addc.lab.local:636
      user                  = CN=svc-ldap,OU=labUsers,DC=lab,DC=local
      password                 = RedactedComplexPassword
      suffix                   = DC=lab,DC=local
      user_tree_dn             = OU=labUsers,DC=lab,DC=local
      user_objectclass         = person
      user_filter                  = (|(memberOf=cn=grp-openstack,OU=labUsers,DC=lab,DC=local)(memberOf=cn=grp-openstack-admin,OU=labUsers,DC=lab,DC=local)(memberOf=memberOf=cn=grp-openstack-demo,OU=labUsers,DC=lab,DC=local))
      user_id_attribute        = sAMAccountName
      user_name_attribute      = sAMAccountName
      user_mail_attribute      = mail
      user_pass_attribute      =
      user_enabled_attribute   = userAccountControl
      user_enabled_mask        = 2
      user_enabled_default     = 512
      user_attribute_ignore    = password,tenant_id,tenants
      group_objectclass        = group
      group_tree_dn            = OU=labUsers,DC=lab,DC=local
      group_filter             = (CN=grp-openstack*)
      group_id_attribute       = cn
      group_name_attribute     = name
      use_tls                  = False
      tls_cacertfile                  =/etc/pki/ca-trust/source/anchors/anchorsaddc.lab.local.pem
      
      query_scope                  = sub
      chase_referrals                  = false
      
      [identity]
      driver = ldap

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

      設定	説明
      url	認証に使用する AD Domain Controller。LDAPS ポート 636 を使用します。
      user	LDAP クエリーに使用する AD アカウントの 識別名。たとえば、Get-ADuser svc-ldap | select DistinguishedName を使用する AD 内の svc-ldap アカウントの 識別名 の値を特定することができます。
      password	上記で使用した AD アカウントのパスワード (プレーンテキスト形式)。
      suffix	AD ドメインの 識別名。この値は、Get-ADDomain | select DistinguishedName を使用して特定することができます。
      user_tree_dn	OpenStack アカウントを含む 組織単位 (OU)。
      user_objectclass	LDAP ユーザーの種別を定義します。AD には person の種別を使用します。
      user_filter	Identity サービスに対して提示するユーザーをフィルターリングします。その結果、grp-openstack グループのメンバーのみに Identity サービスで定義されているパーミッションを付与することができます。この値には、グループの 完全な識別名 が必要です: Get-ADGroup grp-openstack | select DistinguishedName
      user_id_attribute	ユーザー ID に使用する AD 値をマッピングします。
      user_name_attribute	names に使用する AD 値をマッピングします。
      user_mail_attribute	ユーザーのメールアドレスに使用する AD 値をマッピングします。
      user_pass_attribute	この値は空白のままにします。
      user_enabled_attribute	アカウントが有効にされているかどうかを検証する AD の設定。
      user_enabled_mask	アカウントが有効化されているかを判断するために確認すべき値を定義します。ブール値が返されない場合に使用します。
      user_enabled_default	アカウントが有効化されていることを示す AD 値。
      user_attribute_ignore	Identity サービスが無視する必要のあるユーザー属性を定義します。
      group_objectclass	groups に使用する AD 値をマッピングします。
      group_tree_dn	そのユーザーグループを含む 組織単位 (OU)。
      group_filter	Identity サービスに提示するグループをフィルターリングします。
      group_id_attribute	グループ ID に使用する AD 値をマッピングします。
      group_name_attribute	グループ名に使用する AD 値をマッピングします。
      use_tls	TLS を使用するかどうかを定義します。STARTTLS ではなく LDAPS で暗号化する場合には、無効にする必要があります。
      tls_cacertfile	.crt 証明書ファイルへのパスを指定します。
      query_scope	grp-openstack グループに所属するユーザーを特定する場合に、Identity サービスがネスト化された子 OU 内での検索ができるように設定します。
      chase_referrals	false に設定します。この設定により python-ldap が匿名のアクセスによる全参照を追跡しないようにします。

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

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

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

   # sudo docker restart keystone

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

   注記

   この手順を実行しても、OpenStack admin アカウントには実際の AD DS ドメインに対するパーミッションは付与されない点を念頭に置いてください。この場合には、ドメイン という用語は、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

   5. コマンドで NetBIOS 名を指定して、AD DS ドメイン内のユーザー一覧を確認します。

      注記

      リブートまたはサービスの再起動後には、LDAP に対してクエリーを実行できるようになるまでに多少時間がかかる場合があります。

      # openstack user list --domain LAB

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

      # openstack user list --domain default

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

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

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

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

   # 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 は AD DS のユーザー名とパスワードを入力してから、Domain のフィールドにも LAB と入力すると Dashboard にログインすることができます。

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

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_

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 にログインすることができます。

1. IdM にテストユーザーを作成し、そのユーザーを grp-openstack IdM グループに追加します。
2. テストユーザーを demo テナントの _member_ ロールに追加します。
3. IdM テストユーザーの認証情報を使用して Dashboard にログインします。
4. 各タブをクリックし、エラーメッセージなしに正常に表示されているかどうかを確認します。
5. Dashboard を使用してテストインスタンスをビルドします。

1. アンダークラウドノードで、python-novajoin パッケージをインストールします。

   $ sudo yum install python-novajoin

2. アンダークラウドノードで novajoin-ipa-setup スクリプトを実行します。値はデプロイメントに応じて調整します。

   $ sudo /usr/libexec/novajoin-ipa-setup \
       --principal admin \
       --password <IdM admin password> \
       --server <IdM server hostname> \
       --realm <overcloud cloud domain (in upper case)> \
       --domain <overcloud cloud domain> \
       --hostname <undercloud hostname> \
       --precreate

   以下の項では、ここで設定されたワンタイムパスワード (OTP) を使用してアンダークラウドを登録します。

1. novajoin サービスは、デフォルトで無効にされます。有効にするには、以下のように設定します。

   [DEFAULT]
   enable_novajoin = true

2. アンダークラウドノードを IdM に登録するためのワンタイムパスワード (OTP) を設定する必要があります。

   ipa_otp = <otp>

3. neutron の DHCP サーバーによって提供されるオーバークラウドのドメイン名が IdM ドメインと一致するようにします (小文字の kerberos レルム)。

   overcloud_domain_name = <domain>

4. アンダークラウドに適切なホスト名を設定します。

   undercloud_hostname = <undercloud FQDN>

5. アンダークラウドのネームサーバーとして IdM を設定します。

   undercloud_nameservers = <IdM IP>

6. より大きな環境の場合には、novajoin の接続タイムアウト値を確認する必要があります。undercloud.conf で、undercloud-timeout.yaml という名前の新規ファイルへの参照を追加します。

   hieradata_override = /home/stack/undercloud-timeout.yaml

   undercloud-timeout.yaml に以下のオプションを追加します。タイムアウト値は秒単位で指定することができます (例: 5)。

   nova::api::vendordata_dynamic_connect_timeout: <timeout value>
   nova::api::vendordata_dynamic_read_timeout: <timeout value>

7. undercloud.conf ファイルを保存します。

8. アンダークラウドのデプロイコマンドを実行して、既存のアンダークラウドに変更を適用します。

   $ openstack undercloud install

検証

1. keytab ファイルでアンダークラウドのキーエントリーを確認します。

    [root@undercloud-0 ~]# klist -kt
    Keytab name: FILE:/etc/krb5.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       1 04/28/2020 12:22:06 host/undercloud-0.redhat.local@REDHAT.LOCAL
       1 04/28/2020 12:22:06 host/undercloud-0.redhat.local@REDHAT.LOCAL
   
   
    [root@undercloud-0 ~]# klist -kt /etc/novajoin/krb5.keytab
    Keytab name: FILE:/etc/novajoin/krb5.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       1 04/28/2020 12:22:26 nova/undercloud-0.redhat.local@REDHAT.LOCAL
       1 04/28/2020 12:22:26 nova/undercloud-0.redhat.local@REDHAT.LOCAL

2. ホストプリンシパルが含まれるシステム /etc/krb.keytab ファイルをテストします。

    [root@undercloud-0 ~]# kinit -k
    [root@undercloud-0 ~]# klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: host/undercloud-0.redhat.local@REDHAT.LOCAL
   
    Valid starting       Expires              Service principal
    05/04/2020 10:34:30  05/05/2020 10:34:30  krbtgt/REDHAT.LOCAL@REDHAT.LOCAL
   
    [root@undercloud-0 ~]# kdestroy
    Other credential caches present, use -A to destroy all

3. nova プリンシパルが含まれる novajoin /etc/novajoin/krb.keytab ファイルをテストします。

    [root@undercloud-0 ~]# kinit -kt /etc/novajoin/krb5.keytab 'nova/undercloud-0.redhat.local@REDHAT.LOCAL'
    [root@undercloud-0 ~]# klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: nova/undercloud-0.redhat.local@REDHAT.LOCAL
   
    Valid starting       Expires              Service principal
    05/04/2020 10:39:14  05/05/2020 10:39:14  krbtgt/REDHAT.LOCAL@REDHAT.LOCAL

1. アンダークラウドに接続します。

   $ source ~/stackrc

2. DNS ネームサーバーとして IdM を使用するようにコントロールプレーンサブネットを設定します。

   $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>

3. IdM サーバーを使用するように環境ファイルの DnsServers パラメーターを設定します。

   parameter_defaults:
     DnsServers: ["<idm_server_address>"]

   このパラメーターは、通常カスタムの network-environment.yaml ファイルで定義されます。

1. IdM 統合を有効化するには、/usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 環境ファイルのコピーを作成します。

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \
     /home/stack/templates/custom-domain.yaml

2. /home/stack/templates/custom-domain.yaml 環境ファイルを編集して、デプロイメントに適した CloudDomain と CloudName* の値を設定します。以下に例を示します。

   parameter_defaults:
     CloudDomain: lab.local
     CloudName: overcloud.lab.local
     CloudNameInternal: overcloud.internalapi.lab.local
     CloudNameStorage: overcloud.storage.lab.local
     CloudNameStorageManagement: overcloud.storagemgmt.lab.local
     CloudNameCtlplane: overcloud.ctlplane.lab.local

3. オーバークラウドのデプロイプロセスで以下の環境ファイルを追加します。

   • /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml
   • /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml

   • /home/stack/templates/custom-domain.yaml

     以下に例を示します。

     openstack overcloud deploy \
       --templates \
        -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
        -e /home/stack/templates/custom-domain.yaml \

     その結果、デプロイされるオーバークラウドノードは自動的に IdM で登録されるようになります。

4. これで設定されるのは、内部エンドポイント向けの TLS のみです。外部エンドポイントには、/usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml 環境ファイル (カスタムの証明書とキーを追加するように編集する必要あり) で TLS を追加する通常の方法を使用することができます。そのため、openstack deploy コマンドは以下のようになります。

   openstack overcloud deploy \
     --templates \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
     -e /home/stack/templates/custom-domain.yaml \
     -e /home/stack/templates/enable-tls.yaml

5. また、IdM を使用して公開証明書を発行することもできます。その場合には、/usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml 環境ファイルを使用する必要があります。以下に例を示します。

   openstack overcloud deploy \
     --templates \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
      -e /home/stack/templates/custom-domain.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml