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 ノードで、以下の手順を実行します。
SELinux を設定します。
# setsebool -P authlogin_nsswitch_use_ldap=on
出力には、以下のようなメッセージが含まれている場合がありますが、これは無視できます。
Full path required for exclude: net:[4026532245].
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/
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 バックエンドの使用を参照してください。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
追加のバックエンドを設定します。
以下の例では、
LAB
は、Identity サービスドメインとして使用する NetBIOS の名前です。AD DS を統合するための keystone ドメインを作成します。
上記のステップで取得した NetBIOS 名の値をドメイン名として使用します。このアプローチでは、ログインプロセス中に、一貫したドメイン名をユーザーに提示することができます。たとえば、NetBIOS 名が
LAB
の場合には、以下のコマンドを実行します。$ openstack domain create LAB
注記このコマンドが使用できない場合には、
# source overcloudrc-v3
のコマンドを実行して、コマンドラインセッションでの keystone v3 へのアクセスが有効化されているかどうかを確認します。設定ファイルを作成します。
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
が匿名のアクセスによる全参照を追跡しないようにします。
設定ファイルの所有権を keystone ユーザーに変更します。
# chown 42425:42425 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf
keystone サービスを再起動して、変更を適用します。
# sudo docker restart keystone
admin
ユーザーに、ドメインのアクセス権を付与します。注記この手順を実行しても、OpenStack admin アカウントには実際の AD DS ドメインに対するパーミッションは付与されない点を念頭に置いてください。この場合には、ドメイン という用語は、OpenStack が使用する keystone ドメインのことを指しています。
LAB
ドメインのID
を取得します。# openstack domain show LAB +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | enabled | True | | id | 6800b0496429431ab1c4efbb3fe810d4 | | name | LAB | +---------+----------------------------------+
admin ユーザーの
ID
の値を取得します。# openstack user list --domain default | grep admin | 3d75388d351846c6a880e53b2508172a | admin |
admin ロールの
ID
の値を取得します。# openstack role list +----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
返されたドメインおよび admin の ID を使用して、keystone
LAB
ドメインのadmin
ロールにadmin
ユーザーを 追加するコマンドを構築します。# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
コマンドで NetBIOS 名を指定して、AD DS ドメイン内のユーザー一覧を確認します。
注記リブートまたはサービスの再起動後には、LDAP に対してクエリーを実行できるようになるまでに多少時間がかかる場合があります。
# openstack user list --domain LAB
ローカルの 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 リソースへのアクセス権が付与されます。
AD グループの一覧を取得します。
# openstack group list --domain LAB +------------------------------------------------------------------+---------------------+ | ID | Name | +------------------------------------------------------------------+---------------------+ | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack | | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin | | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo | +------------------------------------------------------------------+---------------------+
ロールの一覧を取得します。
# openstack role list +----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin | | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator | +----------------------------------+---------------+
Active Directory グループに上記のロールを 1 つまたは複数追加して、プロジェクトへのアクセス権を付与します。たとえば、
grp-openstack-demo
グループ内のユーザーをdemo
プロジェクトの一般ユーザーにするには、そのグループを_member_
ロールに追加する必要があります。# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
その結果、grp-openstack-demo
のメンバーは、AD DS のユーザー名とパスワードを入力してから、ドメインフィールドにも LAB
と入力すると Dashboard にログインすることができます。

ユーザーに Error: Unable to retrieve container list.
というエラーメッセージが表示され、コンテナーの管理が可能であることが想定されている場合には、SwiftOperator
ロールに追加する必要があります。
1.6.3. Active Directory ユーザーによるプロジェクトへのアクセスの許可
grp-openstack
AD グループのメンバーである AD DS ユーザーには、Dashboard 内の プロジェクト にログインするパーミッションを付与することができます。
AD ユーザーの一覧を取得します。
# openstack user list --domain LAB +------------------------------------------------------------------+----------------+ | ID | Name | +------------------------------------------------------------------+----------------+ | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1 | | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2 | | afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3 | | e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4 | +------------------------------------------------------------------+----------------+
ロールの一覧を取得します。
# openstack role list +----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
一覧表示されたロールの中から 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 にログインすることができます。

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