Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

1.6. Identity サービスの設定

以下のステップでは、Identity サービス (keystone) を AD DS と統合するための準備をします。

注記

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

1.6.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 サービスを実行しているそれぞれの OpenStack ノードで、以下の手順を実行します。

  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.6.2. Active Directory グループのメンバーによるプロジェクトへのアクセスの許可

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

注記

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

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

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

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

  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_

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

domain
注記

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

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

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

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

domain
注記

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