Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
Identity サービスとの統合
Active Directory、IdM、汎用 LDAP を外部認証バックエンドとして使用する方法
OpenStack Documentation Team
rhos-docs@redhat.com
概要
前書き
Identity サービス (コード名 keystone) は Red Hat OpenStack Platform 12 の認証と承認の機能を提供します。
本ガイドは、Microsoft Active Directory Domain Service (AD DS)、Red Hat Identity Management (IdM) および LDAP に Identity サービスを統合する方法について説明します。
第1章 Active Directory との統合
本章では、Identity サービス (keystone) を Active Directory ドメインサービスに統合する方法について説明します。以下のユースケースでは、Identity サービスが特定の Active Directory ドメインサービス (AD DS) のユーザーを認証しつつ、Identity サービスデータベース内で承認設定および重要なサービスアカウントを保持します。この手順を実行すると、Identity サービスは、AD DS に読み取り専用でアクセスしてユーザーアカウントの認証を行う一方で、認証されたアカウントに割り当てる権限を引き続き管理するようになります。
1.1. 主要な用語
- 認証: パスワードを使用して、ユーザーが本人であることを検証するプロセス
- 承認: 認証されたユーザーに対して、アクセスしようとしているシステムの適切なパーミッションが付与されていることを確認するプロセス
- ドメイン: この用語は、AD DS のドメインとは異なり、ユーザー、グループ、プロジェクトの領域確保のために Identity サービスで設定される追加の名前空間のことを指します。異なる LDAP または AD DS 環境のユーザーを認証する別個のドメインを設定することができます。
1.2. 前提条件
本ガイドのデプロイメント例は、以下を前提としています。
- Active Directory ドメインサービスが設定済みで、稼働していること。
- Red Hat OpenStack Platform が設定済みで、稼働していること。
- DNS 名前解決が完全に機能しており、かつ全ホストが適切に登録されていること。
- AD DS 認証トラフィックが LDAPS で暗号化され、ポート 636 を使用していること。
1.3. 影響評価
以下のステップを実行すると、AD DS ユーザーが OpenStack に対して認証を実行して、リソースにアクセスできるようになります。OpenStack のサービスアカウント (keystone、glance など) および承認管理 (パーミッション、ロール、プロジェクト) は Identity サービスのデータベースに残ります。パーミションとロールは、Identity サービスの管理ツールを使用して AD DS アカウントに割り当てられます。
1.3.1. 高可用性のオプション
この設定により、単一の Active Directory Domain Controller に依存するようになるため、Identity サービスがその AD Domain Controller に対して認証できない場合には、プロジェクトユーザーが影響を受けることになります。このリスクを管理するオプションは複数あります。たとえば、Identity サービスが 個別の AD Domain Controller ではなくDNS エイリアスやロードバランシングアプライアンスにクエリーを実行するように設定することが可能です。また、Domain Controller の 1 つが利用できない場合には、keystone が異なる Domain Controller にクエリーを実行するように設定することもできます。詳しくは、「高可用性の設定」を参照してください。
1.4. 停止の要件
- AD DS バックエンドを追加するには、Identity サービスを再起動する必要があります。
- keystone v3 に切り替えるには、全ノード上の Compute サービスを再起動する必要があります。
- ユーザーは、AD DS でアカウントが作成されるまでは、Dashboard にアクセスできません。ダウンタイムを短縮するには、この変更の前に十分余裕をもって AD DS アカウントのプレステージを行うことを検討してください。
1.5. ファイアウォールの設定
ファイアウォールで AD DS と OpenStack の間のトラフィックをフィルタリングしている場合には、以下のポートを介したアクセスを許可する必要があります。
送信元 | 送信先 | 種別 | ポート |
---|---|---|---|
OpenStack コントローラーノード |
Active Directory ドメインコントローラー |
LDAPS |
TCP 636 |
1.6. Active Directory ドメインサービスの設定
本セクションでは、Active Directory の管理者が完了する必要のあるタスクについて説明します。
表1.1 設定手順
タスク |
詳細 |
サービスアカウントの作成 |
サービスアカウントの名前は、 |
ユーザーグループの作成 |
OpenStack へのアクセス権限がユーザーに必要な場合は、このグループに所属する必要があります。ユーザーグループの名前は、 |
プロジェクトグループを作成します。 |
OpenStack の各プロジェクトには、対応する AD グループが必要です。たとえば、 |
サービスアカウントの設定 |
サービスアカウント |
LDAPS 公開鍵のエクスポート |
公開鍵 (秘密鍵ではない) は |
OpenStack 管理者へのキーの送信 |
OpenStack の管理者は、このキーを使用して、OpenStack および Active Directory の LDAPS 通信を暗号化します。 |
AD DS ドメインの NetBIOS 名の取得 |
OpenStack 管理者は、Keystone ドメインにこの名前を使用して、複数の環境間で一貫性のあるドメイン名を指定することができます。 |
たとえば、以下の手順では、Active Directory ドメインコントローラーで実行する PowerShell コマンドが示されています。
1. LDAP ルックアップアカウントを作成します。このアカウントは、Identity サービスが AD DS LDAP サービスにクエリーを実行するのに使用されます。
PS C:\> New-ADUser -SamAccountName svc-ldap -Name "svc-ldap" -GivenName LDAP -Surname Lookups -UserPrincipalName svc-ldap@lab.local -Enabled $false -PasswordNeverExpires $true -Path 'OU=labUsers,DC=lab,DC=local'
2. このアカウントのパスワードを設定し、有効にします。AD ドメインのパスワードの複雑さの要件を満たすパスワードを指定するように要求されます。
PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
3. grp-openstack という名前の OpenStack ユーザーグループを作成します。
PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
4. プロジェクトグループを作成します。
PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local" PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
5. grp-openstack グループに svc-ldap ユーザーを追加します。
PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
6. AD ドメインコントローラーから、証明書 MMC を使用して、DER で暗号化された x509
.cer ファイルとして LDAPS 証明書の (秘密鍵ではなく) 公開鍵 をエクスポートします。このファイルを OpenStack 管理者に送信します。
7. AD DS ドメインから、NetBIOS の名前を取得します。
PS C:\> Get-ADDomain | select NetBIOSName NetBIOSName ----------- LAB
この値を OpenStack 管理者に送信します。
1.7. LDAPS 証明書の設定
1. OpenStack Identity (keystone) を実行中のノードに、LDAPS 公開鍵をコピーし、.cer
から .pem
に変換します。この例では、addc.lab.local.cer
とうい名前の証明書ファイルを使用します。
# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem
2. OpenStack コントローラーに .pem をインストールします。たとえば、Red Hat Enterprise Linux の場合は以下を実行します。
# cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/ # update-ca-trust
3. .pem を .crt に変換して、証明書のディレクトリーにコピーします。
# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt # cp addc.lab.local.crt /etc/ssl/certs/
1.8. Identity サービスの設定
以下のステップでは、Identity サービスを AD DS との統合するための準備をします。
1.8.1. keystone v3 へのコマンドラインアクセスの有効化
コマンドラインから Identity サービスドメインを管理するには、keystone v3 にアクセス可能である必要があります。
keystone サービスを実行しているコントローラーから以下の手順を実行します。
1. 既存の環境変数ファイルのコピーを作成します。director ベースのデプロイメントでは、overcloudrc
と呼ばれます。
$ cp overcloudrc overcloudrc-v3
2. 新しい overcloudrc-v3
ファイルを編集します。
-
以下のように、
OS_AUTH_URL
の値を v2.0 から v3 に変更してください。
export OS_AUTH_URL=https://controllerIP:5000/v3/
-
overcloudrc-v3
の一番下に、以下のエントリーを追加します。
export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default
3. source コマンドでこの設定ファイルを読み込み、現在のコマンドラインセッションでこれらのオプションを有効にします。
$ source overcloudrc-v3
1.8.2. コントローラーの設定
keystone サービスを実行中のコントローラーから以下の手順を実行します。複数のコントローラーがある HA 環境を実行している場合には、各コントローラーでこれらの手順を実行する必要があります。
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 keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
3. Identity サービスが複数のバックエンドを使用するように設定します。
crudini
using 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 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains # crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf assignment driver sql
Red Hat OpenStack Platform director を使用している場合には、/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf が Puppet で管理されている点を認識する必要があります。このため、カスタムの設定を追加しても、openstack overcloud deploy
プロセスを実行する度に上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。今後の director のリリースでは、デプロイ後のスクリプトを使用して、このような設定を自動的に再適用するための Puppet のパラメーターが追加される予定です。
4. Dashboard で複数のドメインを有効にします。以下の行を /etc/openstack-dashboard/local_settings に追加します。
OPENSTACK_API_VERSIONS = { "identity": 3 } OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'
Red Hat OpenStack Platform director を使用している場合には、/etc/openstack-dashboard/local_settings が Puppet で管理されている点を認識する必要があります。このため、カスタムの設定を追加しても、openstack overcloud deploy
プロセスを実行する度に上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。今後の director のリリースでは、デプロイ後のスクリプトを使用して、このような設定を自動的に再適用するための Puppet のパラメーターが追加される予定です。
httpd を再起動して、設定を適用します。
# systemctl restart httpd
5. 追加のバックエンドを設定します。
以下の例では、LAB
は、Identity サービスドメインとして使用する NetBIOS の名前に置き換えます。
a. AD DS を統合するための keystone ドメインを作成します。
上記のステップで取得した NetBIOS 名の値をドメイン名として使用します。このアプローチでは、ログインプロセス中に、一貫したドメイン名をユーザーに提示することができます。たとえば、NetBIOS 名が LAB
の場合には、以下のコマンドを実行します。
# openstack domain create LAB
このコマンドが使用できない場合には、# source overcloudrc-v3
のコマンドを実行して、コマンドラインセッションでの keystone v3 へのアクセスが有効化されているかどうかを確認します。
b. 設定ファイルを作成します。
AD DA バックエンドを追加するには、/var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf (LAB
は、前のステップで作成したドメイン名に置き換えます) という名前の新規ファイルに LDAP 設定を入力します。以下の設定例は、実際に使用する LDAP デプロイメントに合わせて編集する必要があります。
[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 user_allow_create = False user_allow_update = False user_allow_delete = False 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 group_allow_create = False group_allow_update = False group_allow_delete = False use_tls = False tls_cacertfile = /etc/ssl/certs/addc.lab.local.crt query_scope = sub chase_referrals = false [identity] driver = keystone.identity.backends.ldap.Identity
各設定項目について説明します。
設定 | 説明 |
---|---|
|
認証に使用する AD Domain Controller。LDAPS ポート |
|
LDAP クエリーに使用する AD アカウントの 識別名。たとえば、 |
|
上記で使用した AD アカウントのパスワード (プレーンテキスト形式) |
|
AD ドメインの 識別名。この値は、 |
|
OpenStack アカウントを含む 組織単位 (OU) |
|
LDAP ユーザーの種別を定義します。AD には |
|
Identity サービスに対して提示するユーザーをフィルタリングすることにより、grp-openstack グループのメンバーのみに Identity サービスで定義されているパーミッションを付与することができます。この値には、グループの完全な 識別名 が必要です ( |
|
ユーザー ID に使用する AD 値をマッピングします。 |
|
names に使用する AD 値をマッピングします。 |
|
ユーザーのメールアドレスに使用する AD 値をマッピングします。 |
|
この値は空白のままにします。 |
|
アカウントが有効にされているかどうかを検証する AD の設定 |
|
アカウントが有効化されているかを判断するために確認すべき値を定義します。ブール値が返されない場合に使用します。 |
|
アカウントが有効化されていることを示す AD 値 |
|
Identity サービスが無視する必要のあるユーザー属性を定義します。 |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
groups に使用する AD 値をマッピングします。 |
|
そのユーザーグループを含む 組織単位 (OU) |
|
Identity サービスに提示するグループをフィルタリングします。 |
|
グループ ID に使用する AD 値をマッピングします。 |
|
グループ名に使用する AD 値をマッピングします。 |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
TLS を使用するかどうかを定義します。STARTTLS ではなく LDAPS で暗号化する場合には、無効にする必要があります。 |
|
.crt 証明書ファイルへのパスを指定します。 |
|
|
|
|
6. 設定ファイルの所有権を keystone ユーザーに変更します。
# chown keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf
7. keystone サービスを再起動して、変更を適用します。
# sudo docker exec -it keystone pkill -HUP -f keystone
8. admin ユーザーにドメインへのアクセス権を付与します。
この手順を実行しても、OpenStack admin アカウントには実際の AD DS ドメインに対するパーミッションは付与されない点を念頭に置いてください。この場合には、ドメインという用語は、OpenStack が使用する keystone ドメインのことを指しています。
a. LAB
ドメインの ID
を取得します。
# openstack domain show LAB +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | enabled | True | | id | 6800b0496429431ab1c4efbb3fe810d4 | | name | LAB | +---------+----------------------------------+
b. admin ユーザーの ID
の値を取得します。
# openstack user list --domain default | grep admin | 3d75388d351846c6a880e53b2508172a | admin |
c. admin ロールの ID
の値を取得します。
# openstack role list +----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
d. 返されたドメインおよび管理 ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。
# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
9. コマンドで NetBIOS 名を指定して、AD DS ドメイン内のユーザー一覧を確認します。
リブートまたはサービスの再起動後には、LDAP に対してクエリーを実行できるようになるまでに多少時間がかかる場合があります。
# openstack user list --domain LAB
10. ローカルの Identity サービスデータベース内のサービスアカウントを確認します。
# openstack user list --domain default
1.8.3. Compute が keystone v3 を使用するようにするための設定
Compute はデフォルトで keystone v2.0 を使用するように設定されているので、マルチドメイン機能を使用するためには、keystone v3 を使用するように設定する必要があります。
1. 各コンピュートノードとコントローラーで keystone_authtoken
値を変更します。
# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
2. コントローラーでサービスを再起動して、変更を適用します。
# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service # sudo docker exec -it keystone pkill -HUP -f keystone
3. 各コンピュートノードでサービスを再起動して、変更を適用します。
# systemctl restart openstack-nova-compute.service
1.8.4. Block Storage が keystone v3 を使用するようにするための設定
keystone v3 に対して認証を実行するには、Block Storage (cinder) を設定する必要もあります。
/etc/cinder/cinder.conf を編集します。
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
-
auth_uri
のcontrollerIP
の箇所をコントローラーの IP アドレスに置き換えます。デプロイメントにコントローラーが複数ある場合には、コントローラーの IP アドレスの代わりに keystone エンドポイントの仮想 IP アドレスを使用すべきです。
-
全コントローラーで
cinder-api
を再起動します。# systemctl restart openstack-cinder-api
全コントローラーで
cinder-scheduler
を再起動します。# systemctl restart openstack-cinder-scheduler
cinder-volume
を再起動します (1 台のコントローラーでのみ)。# pcs resource restart openstack-cinder-volume
1.8.5. 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
グループに追加します。
以下のステップでは、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 のユーザー名とパスワードを入力して Dashboard にログインすることができます。また、ドメインフィールドに LAB
と入力してログインすることも可能です。
ユーザーに「Error: Unable to retrieve container list.」というエラーメッセージが表示され、コンテナーの管理が可能であることが想定されている場合には、SwiftOperator ロールに追加する必要があります。
1.8.6. 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 のユーザー名とパスワードを入力してから、ドメインのフィールドにも LAB
と入力すると Dashboard にログインすることができます。
ユーザーに「Error: Unable to retrieve container list.」というエラーメッセージが表示され、コンテナーの管理が可能であることが想定されている場合には、SwiftOperator ロールに追加する必要があります。
1.9. ドメインタブへのアクセスの許可
admin
ユーザーが ドメイン
タブを見えるようにするには、そのユーザーを default
ドメインで admin
ロールに割り当てる必要があります。
admin
ユーザーの UUID を確認します。$ openstack user list | grep admin | a6a8adb6356f4a879f079485dad1321b | admin |
default
ドメインのadmin
ロールをadmin
ユーザーに追加します。$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
その結果、
admin
ユーザーにDomain
タブが見えるようになります。
1.10. 新規プロジェクトの作成
上記の統合ステップが完了した後に新規プロジェクトを作成する場合には、Default
ドメインと、自分で作成した keystone ドメインのどちらに作成するかを決定する必要があります。これは、ワークフローとユーザーアカウントの管理方法を考慮して決定することができます。Default ドメインは、サービスアカウントと admin プロジェクトの管理に使用する内部ドメインとして考えることができます。また、分離の目的で、AD でバッキングされているユーザーを異なる keystone ドメインを使用することも可能です。
1.11. Dashboard へのログインプロセスの変更
Identity サービスに複数のドメインを設定すると、Dashboard のログインメージに新しい ドメイン フィールドが有効になります。
ユーザーは、ログイン認証情報にマッチするドメインを入力する必要があります。このフィールドには、keystone で提示されるドメインの 1 つを手動で入力する必要があります。利用可能なエントリーを表示するには、openstack コマンドを使用します。
以下の例では、AD DS アカウントには LAB
ドメインを指定する必要があります。admin のような組み込みの keystone アカウントには、ドメインに Default
を指定する必要があります。
# openstack domain list +----------------------------------+---------+---------+----------------------------------------------------------------------+ | ID | Name | Enabled | Description | +----------------------------------+---------+---------+----------------------------------------------------------------------+ | 6800b0496429431ab1c4efbb3fe810d4 | LAB | True | | | default | Default | True | Owns users and tenants (i.e. projects) available on Identity API v2. | +----------------------------------+---------+---------+----------------------------------------------------------------------+
1.12. コマンドラインへの変更
特定のコマンドでは、対象のドメインを指定する必要がある場合があります。たとえば、以下のコマンドに --domain LAB
を追加すると、LAB ドメイン内のユーザー (grp-openstack グループのメンバー) が返されます。
# openstack user list --domain LAB
--domain Default
を追加すると、組み込みの keystone アカウントが返されます。
# openstack user list --domain Default
1.13. AD DS 統合のテスト
以下の手順では、Dashboard の機能へのユーザーアクセスをテストして、AD DS の統合を検証します。
1. AD にテストユーザーを作成し、そのユーザーを grp-openstack
AD DSグループに追加します。
2. テストユーザーを demo
テナントの _member_
ロールに追加します。
3. AD テストユーザーの認証情報を使用して Dashboard にログインします。
4. 各タブをクリックし、エラーメッセージなしに正常に表示されているかどうかを確認します。
5. Dashboard を使用してテストインスタンスをビルドします。
上記の手順で問題が発生した場合には、ステップ 3 から 5 までを組み込みの admin アカウントで実行してください。正常に実行できた場合には、OpenStack が想定通りに機能していることが実証されるので、問題は AD と Identity の統合設定の間のどこかにあることになります。「トラブルシューティング」を参照してください。
1.14. 高可用性の設定
keystone v3 が有効化されている場合には、ドメインの設定ファイルに複数の AD Domain Controller をリストして、この設定を高可用性にすることが可能です。
1. 2 番目のサーバーを url
エントリーに追加します。たとえば、keystone.LAB.conf ファイル内の url
設定を更新すると、Identity サービスは全クエリートラフィックをリスト内で 1 番目のドメインコントローラーである addc.lab.local に送信します。
url = ldaps://addc.lab.local,ldaps://addc2.lab.local
addc.lab.local が利用できないためにクエリーが失敗した場合には、Identity サービスはリストに記載されている次のサーバー addc2.lab.local にクエリーの送信を試みます。この設定では、ラウンドロビン式にはクエリーが実行されないので、ロードバランスのソリューションとしては考慮できない点に注意してください。
2. /etc/openldap/ldap.conf でネットワークのタイムアウトを設定します。
NETWORK_TIMEOUT 2
また、コントローラーとドメインコントローラーの間でファイアウォールが設定されている場合には、ドメインコントローラーがダイアログを表示せずにコントローラーからのパケットを破棄してしまわないように設定すべきです。このように設定すると、python-keystoneclient が機能停止を適切に検知して、リスト内の次のドメインコントローラーに要求をリダイレクトすることができます。
クエリーがリストの第 2 の LDAP サーバーに転送される間に接続の遅延が発生する可能性があります。これは、第 2 のサーバーへの接続を試みるには、第 1 のサーバーがタイムアウトになる必要があるためです。
1.15. 非管理ユーザー用の RC ファイルの作成
非管理ユーザー用の RC ファイルを作成する必要がある場合があります。以下に例を示します。
$ cat overcloudrc-v3-user1 # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_USERNAME=user1 export NOVA_VERSION=1.1 export OS_PROJECT_NAME=demo export OS_PASSWORD=RedactedComplexPassword export OS_NO_CACHE=True export COMPUTE_API_VERSION=1.1 export no_proxy=,10.0.0.5,192.168.2.11 export OS_CLOUDNAME=overcloud export OS_AUTH_URL=https://10.0.0.5:5000/v3 export OS_AUTH_TYPE=password export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available" export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=LAB
1.16. トラブルシューティング
1.16.1. LDAP 接続のテスト
Active Directory Domain Controller に対してテストクエリーをリモートで実行するには、ldapsearch を使用します。クエリーが成功した場合には、ネットワーク接続が機能しており、AD DS サービスが稼働中であることを確認できます。以下の例では、テストクエリーはサーバー addc.lab.local のポート636 に対して実行されます。
# ldapsearch -Z -x -H ldaps://addc.lab.local:636 -D "svc-ldap@lab.local" -W -b "OU=labUsers,DC=lab,DC=local" -s sub "(cn=*)" cn
ldapsearch は、openldap-clients パッケージに含まれています。このパッケージは、# yum install openldap-clients
のコマンドを実行するとインストールすることができます。
1.16.2. 証明書トラストの設定テスト
ldapsearch のテストの際に Peer's Certificate issuer is not recognized.
というエラーを受け取った場合には、TLS_CACERTDIR
パスが正しく設定されていることを確認してください。以下に例を示します。
- /etc/openldap/ldap.conf
TLS_CACERTDIR /etc/openldap/certs
一時的な回避策として、証明書の検証を無効にすることを検討してください。
この設定は、永続的には使用しないでください。
- /etc/openldap/ldap.conf
TLS_REQCERT allow
この値を設定した後に ldapsearch クエリーが機能した場合には、証明書トラストが正しく設定されているかどうかをレビューする必要があります。
1.16.3. ポートアクセスのテスト
nc を使用して、LDAPS ポート (636) がリモートでアクセス可能であることを確認します。この例では、サーバー addc.lab.local に対してプローブを実行します。ctrl-c を押してプロンプトを終了します。
# nc -v addc.lab.local 636 Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 192.168.200.10:636. ^C
接続を確立できなかった場合には、ファイアウォールの設定に問題がある可能性があります。
第2章 Identity Management の統合
本章では、Identity サービス (keystone) を Red Hat Identity Management と統合する方法について説明します。
以下のユースケースでは、Identity サービスが特定の Red Hat Identity Management (IdM) のユーザーを認証しつつ、Identity サービスデータベース内で承認設定および重要なサービスアカウントを保持します。
この手順を実行すると、Identity サービスは、IdM に読み取り専用でアクセスしてユーザーアカウントの認証を行う一方で、認証されたアカウントに割り当てる権限を引き続き管理するようになります。
novajoin を使用した追加の統合オプションについては、「3章novajoin を使用した IdM との統合」を参照してください。
2.1. 主要な用語
- 認証: パスワードを使用して、ユーザーが本人であることを検証するプロセス
- 承認: 認証されたユーザーに対して、アクセスしようとしているシステムの適切なパーミッションが付与されていることを確認するプロセス
- ドメイン: Identity サービス内で設定する追加のバックエンドのことを指します。たとえば、Identity サービスは、外部の IdM 環境内のユーザーを認証するように設定することができます。このように設定されたユーザーの集合は、ドメインとして考えることができます。
2.2. 前提条件
本ガイドのデプロイメント例は、以下を前提としています。
- Red Hat Identity Management が設定済みで、稼働していること。
- Red Hat OpenStack Platform が設定済みで、稼働していること。
- DNS 名前解決が完全に機能しており、かつ全ホストが適切に登録されていること。
2.3. 影響評価
以下のステップを実行すると、IdM ユーザーが OpenStack に対して認証を実行して、リソースにアクセスできるようになります。OpenStack のサービスアカウント (keystone、glance など) および承認管理 (パーミッションとロール) は Identity サービスのデータベースに残ります。パーミションとロールは、Identity サービスの管理ツールを使用して IdM アカウントに割り当てられます。
2.3.1. 高可用性のオプション
この設定により、単一の IdM に依存するようになるため、Identity サービスがその IdM サーバー に対して認証できない場合には、プロジェクトユーザーが影響を受けることになります。このリスクを管理するオプションは複数あります。たとえば、keystone が個別の IdM サーバーではなくDNS エイリアスやロードバランシングアプライアンスにクエリーを実行するように設定することが可能です。また、IdM サーバー の 1 つが利用できない場合には、keystone が異なる IdM サーバーにクエリーを実行するように設定することもできます。詳しくは、「高可用性の設定」を参照してください。
2.4. 停止の要件
- IdM バックエンドを追加するには、Identity サービスを再起動する必要があります。
- keystone v3 に切り替えるには、全ノード上の Compute サービスを再起動する必要があります。
- ユーザーは、IdM でアカウントが作成されるまでは、Dashboard にアクセスできません。ダウンタイムを短縮するには、この変更の前に十分余裕をもって IdM アカウントのプレステージを行うことを検討してください。
2.5. ファイアウォールの設定
ファイアウォールが IdM と OpenStack の間のトラフィックをフィルタリングしている場合には、以下のポートを介したアクセスを許可する必要があります。
送信元 | 送信先 | 種別 | ポート |
---|---|---|---|
OpenStack コントローラーノード |
Red Hat Identity Management |
LDAPS |
TCP 636 |
2.6. IdM サーバーの設定
IdM サーバーで、以下のコマンドを実行します。
1. LDAP ルックアップアカウントを作成します。このアカウントは、Identity サービスが IdM の LDAP サービスにクエリーを実行するのに使用します。
# kinit admin # ipa user-add First name: OpenStack Last name: LDAP User [radministrator]: svc-ldap
作成が完了したら、このアカウントのパスワード期限の設定を確認してください。
2. grp-openstack という名前の OpenStack ユーザーグループを作成します。OpenStack Identity でパーミッションを割り当てることができるのは、このグループのメンバーのみです。
# ipa group-add --desc="OpenStack Users" grp-openstack
3. svc-ldap アカウントのパスワードを設定して、grp-openstack グループに追加します。
# ipa passwd svc-ldap # ipa group-add-member --users=svc-ldap grp-openstack
2.7. LDAPS 証明書の設定
1. IdM の環境で、LDAPS 証明書を見つけます。このファイルの場所は、/etc/openldap/ldap.conf で確認することができます。
TLS_CACERT /etc/ipa/ca.crt
2. OpenStack Identity (keystone) を実行しているノードにファイルをコピーします。たとえば、以下のコマンドは、scp を使用して、ca.crt を node.lab.local という名前のコントラーノードにコピーします。
scp /etc/ipa/ca.crt root@node.lab.local:/root/
3. コントローラーノードで、.crt を .pem に変換します。
# openssl x509 -in ca.crt -out ca.pem -outform PEM
4. OpenStack コントローラーに .pem をインストールします。たとえば、Red Hat Enterprise Linux の場合は以下を実行します。
# cp ca.pem /etc/pki/ca-trust/source/anchors/ # update-ca-trust
5. .crt を証明書のディレクトリーにコピーします。
# cp ca.crt /etc/ssl/certs/
2.8. Identity サービスの設定
以下のステップでは、IdM との統合に備えて、Identity サービスの準備を行います。
2.8.1. keystone v3 へのコマンドラインアクセスの有効化
コマンドラインから Identity サービスドメインを管理するには、keystone v3 にアクセス可能である必要があります。
keystone サービスを実行しているコントローラーから以下の手順を実行します。
1. 既存の環境変数ファイルのコピーを作成します。director ベースのデプロイメントでは、overcloudrc
と呼ばれます。
$ cp overcloudrc overcloudrc-v3
2. 新しい overcloudrc-v3
ファイルを編集します。
-
以下のように、
OS_AUTH_URL
の値を v2.0 から v3 に変更してください。
export OS_AUTH_URL=https://controllerIP:5000/v3/
-
overcloudrc-v3
の一番下に、以下のエントリーを追加します。
export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default
3. source コマンドでこの設定ファイルを読み込み、現在のコマンドラインセッションでこれらのオプションを有効にします。
$ source overcloudrc-v3
2.8.2. コントローラーの設定
keystone サービスを実行しているコントローラーから以下の手順を実行します。
1. SELinux を設定します。
# setsebool -P authlogin_nsswitch_use_ldap=on
2. domains ディレクトリーを作成します。
# mkdir /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/ # chown keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
3. Identity サービスが複数のバックエンドを使用するように設定します。
crudini
using 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 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains # crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf assignment driver sql
Red Hat OpenStack Platform director を使用している場合には、/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf が Puppet で管理されている点を認識する必要があります。このため、カスタムの設定を追加しても、openstack overcloud deploy
プロセスを実行する度に上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。今後の director のリリースでは、デプロイ後のスクリプトを使用して、このような設定を自動的に再適用するための Puppet のパラメーターが追加される予定です。
4. Dashboard で複数のドメインを有効にします。以下の行を /etc/openstack-dashboard/local_settings に追加します。
OPENSTACK_API_VERSIONS = { "identity": 3 } OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'
Red Hat OpenStack Platform director を使用している場合には、/etc/openstack-dashboard/local_settings が Puppet で管理されている点を認識する必要があります。このため、カスタムの設定を追加しても、openstack overcloud deploy
プロセスを実行する度に上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。今後の director のリリースでは、デプロイ後のスクリプトを使用して、このような設定を自動的に再適用するための Puppet のパラメーターが追加される予定です。
httpd を再起動して、設定を適用します。
# systemctl restart httpd
5. 追加のバックエンドを設定します。
a. IdM 統合のための keystone ドメインを作成します。
新しい keystone ドメインに使用する名前を選択し、ドメインを作成します。たとえば、以下のコマンドは LAB
という名前の keystone ドメインを作成します。
# openstack domain create LAB
このコマンドが使用できない場合には、コマンドラインセッションでの keystone v3 へのアクセスが有効化されているかどうかを確認してください。
b. 設定ファイルを作成します。
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 = user_allow_create = False user_allow_update = False user_allow_delete = False tls_cacertfile = /etc/ssl/certs/ca.crt [identity] driver = keystone.identity.backends.ldap.Identity
各設定項目について説明します。
設定 | 説明 |
---|---|
|
認証に使用する IdM サーバー。LDAPS ポート |
|
LDAP クエリーに使用する IdM 内のアカウント |
|
上記で使用した IdM アカウントのパスワード (プレーンテキスト形式) |
|
Identity サービスに対して提示するユーザーをフィルタリングすることにより、grp-openstack グループのメンバーのみに Identity サービスで定義されているパーミッションを付与することができます。 |
|
IdM 内の OpenStack アカウントへのパス |
|
LDAP ユーザーの種別を定義します。IdM には |
|
ユーザー ID に使用する IdM 値をマッピングします。 |
|
names に使用する IdM 値をマッピングします。 |
|
ユーザーのメールアドレスに使用する IdM 値をマッピングします。 |
|
この値は空白のままにします。 |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
6. 設定ファイルの所有権を keystone ユーザーに変更します。
# chown keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf
7. admin ユーザーにドメインへのアクセス権を付与します。
この手順を実行しても、OpenStack admin アカウントには IdM のパーミッションは付与されません。この場合には、ドメインという用語は、OpenStack が使用する keystone ドメインのことを指しています。
a. LAB ドメインの ID
を取得します。
# openstack domain show LAB +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | enabled | True | | id | 6800b0496429431ab1c4efbb3fe810d4 | | name | LAB | +---------+----------------------------------+
b. admin ユーザーの ID
の値を取得します。
# openstack user list --domain default | grep admin | 3d75388d351846c6a880e53b2508172a | admin |
c. admin ロールの ID
の値を取得します。
# openstack role list +----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
d. 返されたドメインおよび管理 ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。
# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
8. keystone サービスを再起動して、変更を適用します。
# sudo docker exec -it keystone pkill -HUP -f keystone
9. コマンドで keystone ドメイン名を指定して、IdM ドメイン内のユーザー一覧を確認します。
# openstack user list --domain LAB
10. ローカルの keystone データベース内のサービスアカウントを確認します。
# openstack user list --domain default
2.8.3. Compute が keystone v3 を使用するようにするための設定
Compute はデフォルトで keystone v2.0 を使用するように設定されているので、マルチドメイン機能を使用するためには、keystone v3 を使用するように設定する必要があります。
1. 各コンピュートノードとコントローラーで keystone_authtoken
値を変更します。
# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
2. コントローラーでサービスを再起動して、変更を適用します。
# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service # sudo docker exec -it keystone pkill -HUP -f keystone
3. 各コンピュートノードでサービスを再起動して、変更を適用します。
# systemctl restart openstack-nova-compute.service
2.8.4. Block Storage が keystone v3 を使用するようにするための設定
keystone v3 に対して認証を実行するには、Block Storage (cinder) を設定する必要もあります。
/etc/cinder/cinder.conf を編集します。
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
-
auth_uri
のcontrollerIP
の箇所をコントローラーの IP アドレスに置き換えます。デプロイメントにコントローラーが複数ある場合には、コントローラーの IP アドレスの代わりに keystone エンドポイントの仮想 IP アドレスを使用すべきです。
-
全コントローラーで
cinder-api
を再起動します。# systemctl restart openstack-cinder-api
全コントローラーで
cinder-scheduler
を再起動します。# systemctl restart openstack-cinder-scheduler
cinder-volume
を再起動します (1 台のコントローラーでのみ)。# pcs resource restart openstack-cinder-volume
2.8.5. IdM ユーザーによるプロジェクトへのアクセスの許可
grp-openstack IdM グループのメンバーである IdM ユーザーには、Dashboard 内のプロジェクトにログインするパーミッションを付与することができます。
1. IdM ユーザーの一覧を取得します。
# openstack user list --domain LAB +------------------------------------------------------------------+----------------+ | ID | Name | +------------------------------------------------------------------+----------------+ | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1 | | 12c062fidm5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | 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 のユーザー名とパスワードを入力してから、ドメインのフィールドにも LAB
と入力すると Dashboard にログインすることができます。
ユーザーに「Error: Unable to retrieve container list.」というエラーメッセージが表示され、コンテナーの管理が可能であることが想定されている場合には、SwiftOperator ロールに追加する必要があります。
2.9. ドメインタブへのアクセスの許可
admin
ユーザーが ドメイン
タブを見えるようにするには、そのユーザーを default
ドメインで admin
ロールに割り当てる必要があります。
admin
ユーザーの UUID を確認します。$ openstack user list | grep admin | a6a8adb6356f4a879f079485dad1321b | admin |
default
ドメインのadmin
ロールをadmin
ユーザーに追加します。$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
その結果、
admin
ユーザーにDomain
タブが見えるようになります。
2.10. 新規プロジェクトの作成
上記の統合ステップが完了した後に新規プロジェクトを作成する場合には、Default
ドメインと、自分で作成した keystone ドメインのどちらに作成するかを決定する必要があります。これは、ワークフローとユーザーアカウントの管理方法を考慮して決定することができます。Default
ドメインは、サービスアカウントと admin
プロジェクトに使用する内部ドメインとして考えることができるので、AD でバッキングされているユーザーを異なる keystone ドメインに内に配置することは理にかなっています。これは、IdM ユーザーが管理されているのと全く同じ keystone ドメインである必要はありません。また、分離の目的で複数の keystone ドメインを使用することも可能です。
2.10.1. Dashboard へのログインプロセスの変更
Identity サービスに複数のドメインを設定すると、Dashboard のログインメージに新しい ドメイン フィールドが有効になります。
ユーザーは、ログイン認証情報にマッチするドメインを入力する必要があります。このフィールドには、keystone で提示されるドメインの 1 つを手動で入力する必要があります。利用可能なエントリーを表示するには、openstack コマンドを使用します。
以下の例では、IdM アカウントには LAB
ドメインを指定する必要があります。admin のような組み込みの keystone アカウントには、ドメインに Default
を指定する必要があります。
# openstack domain list +----------------------------------+---------+---------+----------------------------------------------------------------------+ | ID | Name | Enabled | Description | +----------------------------------+---------+---------+----------------------------------------------------------------------+ | 6800b0496429431ab1c4efbb3fe810d4 | LAB | True | | | default | Default | True | Owns users and tenants (i.e. projects) available on Identity API v2. | +----------------------------------+---------+---------+----------------------------------------------------------------------+
2.10.2. コマンドラインへの変更
特定のコマンドでは、対象のドメインを指定する必要がある場合があります。たとえば、以下のコマンドに --domain LAB
を追加すると、LAB ドメイン内のユーザー (grp-openstack グループのメンバー) が返されます。
# openstack user list --domain LAB
--domain Default
を追加すると、組み込みの keystone アカウントが返されます。
# openstack user list --domain Default
2.10.3. IdM 統合のテスト
以下の手順では、Dashboard の機能へのユーザーアクセスをテストして、IdM の統合を検証します。
1. IdM にテストユーザーを作成し、そのユーザーを grp-openstack
IdM グループに追加します。
2. テストユーザーを demo
テナントの _member_
ロールに追加します。
3. IdM テストユーザーの認証情報を使用して Dashboard にログインします。
4. 各タブをクリックし、エラーメッセージなしに正常に表示されているかどうかを確認します。
5. Dashboard を使用してテストインスタンスをビルドします。
上記の手順で問題が発生した場合には、ステップ 3 から 5 までを組み込みの admin アカウントで実行してください。正常に実行できた場合には、OpenStack が想定通りに機能していることが実証されるので、問題は IdM と Identity の統合設定の間のどこかにあることになります。「トラブルシューティング」を参照してください。
2.11. 高可用性の設定
keystone v3 が有効化されている場合には、ドメインの設定ファイルに複数の IdM サーバーをリストして、この設定を高可用性にすることが可能です。
1. 2 番目のサーバーを url
エントリーに追加します。たとえば、keystone.LAB.conf ファイル内の url
設定を更新すると、Identity サービスは全クエリートラフィックをリスト内で 1 番目の IdM サーバーである idm.lab.local に送信します。
url = ldaps://idm.lab.local,ldaps://idm2.lab.local
idm.lab.local が利用できないためにクエリーが失敗した場合には、Identity サービスはリストに記載されている次のサーバー idm2.lab.local にクエリーの送信を試みます。この設定では、ラウンドロビン式にはクエリーが実行されないので、ロードバランスのソリューションとしては考慮できない点に注意してください。
2. /etc/openldap/ldap.conf でネットワークのタイムアウトを設定します。
NETWORK_TIMEOUT 2
また、コントローラーと IdM サーバーの間でファイアウォールが設定されている場合には、IdM サーバーがダイアログを表示せずにコントローラーからのパケットを破棄してしまわないように設定すべきです。このように設定すると、python-keystoneclient が機能停止を適切に検知して、リスト内の次の IdM サーバーに要求をリダイレクトすることができます。
クエリーがリストの第 2 の IdM サーバーに転送される間に接続の遅延が発生する可能性があります。これは、第 2 のサーバーへの接続を試みるには、第 1 のサーバーがタイムアウトになる必要があるためです。
2.12. 非管理ユーザー用の RC ファイルの作成
非管理ユーザー用の RC ファイルを作成する必要がある場合があります。以下に例を示します。
$ cat overcloudrc-v3-user1 # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_USERNAME=user1 export NOVA_VERSION=1.1 export OS_PROJECT_NAME=demo export OS_PASSWORD=RedactedComplexPassword export OS_NO_CACHE=True export COMPUTE_API_VERSION=1.1 export no_proxy=,10.0.0.5,192.168.2.11 export OS_CLOUDNAME=overcloud export OS_AUTH_URL=https://10.0.0.5:5000/v3 export OS_AUTH_TYPE=password export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available" export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=LAB
2.13. トラブルシューティング
2.13.1. LDAP 接続のテスト
IdM サーバーに対してテストクエリーをリモートで実行するには、ldapsearch を使用します。クエリーが成功した場合には、ネットワーク接続が機能しており、IdM サービスが稼働中であることを確認できます。以下の例では、テストクエリーはサーバーidm.lab.local のポート636 に対して実行されます。
# ldapsearch -D "cn=directory manager" -H ldaps://idm.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword
ldapsearch は、openldap-clients パッケージに含まれています。このパッケージは、# yum install openldap-clients
のコマンドを実行するとインストールすることができます。
2.13.2. ポートアクセスのテスト
nc を使用して、LDAPS ポート (636) がリモートでアクセス可能であることを確認します。この例では、サーバー idm.lab.local に対してプローブを実行します。ctrl-c を押してプロンプトを終了します。
# nc -v idm.lab.local 636 Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 192.168.200.10:636. ^C
接続を確立できなかった場合には、ファイアウォールの設定に問題がある可能性があります。
第3章 novajoin を使用した IdM との統合
novajoin により、使用するノードをデプロイメントプロセスの一部として Red Hat Identity Manager (IdM) に登録できます。その結果、OpenStack デプロイメントで、ID、kerberos 認証情報、アクセス制御などの IdM の機能を統合することができます。
現在、novajoin を使用した IdM の登録は、アンダークラウドとオーバークラウドのノードのみで利用可能です。オーバークラウドインスタンス向けの novajoin の統合は、今後のリリースでサポートされるようになる見込みです。
3.1. アンダークラウドでの novajoin のインストールと設定
3.1.1. CA へのアンダークラウドの追加
オーバークラウドをデプロイする前には、アンダークラウドを認証局 (CA) に追加する必要があります。
アンダークラウドノードで、
python-novajoin
パッケージをインストールします。$ sudo yum install python-novajoin
アンダークラウドノードで
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) を使用してアンダークラウドを登録します。
3.1.2. アンダークラウドを IdM に追加します。
以下の手順では、アンダークラウドを IdM に登録して novajoin を設定します。
novajoin サービスは、デフォルトで無効にされます。有効化するには、
undercloud.conf
にエントリーを追加します。enable_novajoin = true
アンダークラウドノードをIdM に登録するためのワンタイムパスワード (OTP) を設定する必要があります。
ipa_otp = <otp>
neutron の DHCP サーバーによって提供されるオーバークラウドのドメイン名が IdM ドメインと一致するようにします (小文字の kerberos レルム)。
overcloud_domain_name = <domain>
アンダークラウドに適切なホスト名を設定します。
undercloud_hostname = <undercloud FQDN>
アンダークラウドのネームサーバーとして IdM を設定します。
undercloud_nameservers = <IdM IP>
より大きな環境の場合には、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>
-
undercloud.conf
ファイルを保存します。 アンダークラウドのデプロイコマンドを実行して、既存のアンダークラウドに変更を適用します。
$ openstack undercloud install
3.2. オーバークラウドでの novajoin のインストールと設定
以下の項では、オーバークラウドノードを IdM で登録する方法について説明します。
3.2.1. オーバークラウド DNS の設定
IdM 環境を自動検出して、登録をより簡単にするには、IdM を DNS サーバーとして使用することを検討してください。
アンダークラウドに接続します。
$ source ~/stackrc
DNS ネームサーバーとして IdM を使用するためのコントロールプレーンサブネットを設定します。
$ openstack subnet set ctlplane-subnet --dns-nameserver <idm_server_address>
IdM サーバーを使用するように環境ファイルの
DnsServers
パラメーターを設定します。parameter_defaults: DnsServers: ["<idm_server_address>"]
このパラメーターは、通常カスタムの
network-environment.yaml
ファイルで定義されます。
3.2.2. novajoin を使用するためのオーバークラウドの設定
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
/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
オーバークラウドのデプロイプロセスで以下の環境ファイルを追加します。
-
/usr/share/openstack-tripleo-heat-templates/environments/enable-internal-tls.yaml
-
/usr/share/openstack-tripleo-heat-templates/environments/tls-everywhere-endpoints-dns.yaml
/home/stack/templates/custom-domain.yaml
以下に例を示します。
openstack overcloud deploy \ --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/enable-internal-tls.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/tls-everywhere-endpoints-dns.yaml \ -e /home/stack/templates/custom-domain.yaml \
その結果、デプロイされるオーバークラウドノードは自動的に IdM で登録されるようになります。
-
これで設定されるのは、内部エンドポイント向けの TLS のみです。外部エンドポイントには、
./tripleo-heat-templates/environments/enable-tls.yaml
環境ファイル (カスタムの証明書とキーを追加するように編集する必要あり) で TLS を追加する通常の方法を使用することができます。そのため、openstack deploy
コマンドは以下のようになります。openstack overcloud deploy \ --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/enable-internal-tls.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/tls-everywhere-endpoints-dns.yaml \ -e /home/stack/templates/custom-domain.yaml \ -e /home/stack/templates/enable-tls.yaml
また、IdM を使用して公開証明書を発行することもできます。その場合には、
./tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml
環境ファイルを使用する必要があります。以下に例を示します。openstack overcloud deploy \ --templates \ -e ./tripleo-heat-templates/environments/enable-internal-tls.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/tls-everywhere-endpoints-dns.yaml \ -e /home/stack/templates/custom-domain.yaml \ -e ./tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml
3.3. IdM におけるノードの検証
IdM でオーバークラウドノードを特定し、ホストのエントリーに
Keytab:True
が含まれていることを確認します。$ ipa host-show overcloud-node-01 Host name: overcloud-node-01.lab.local Principal name: host/overcloud-node-01.lab.local@LAB.LOCAL Principal alias: host/overcloud-node-01.lab.local@LAB.LOCAL SSH public key fingerprint: <snip> Password: False Keytab: True Managed by: overcloud-node-01.lab.local
そのノードに SSH 接続し、sssd が IdM ユーザーをクエリーできることを確認します。たとえば、
susan
という名前の IdM ユーザーをクエリーするには、以下のコマンドを実行します。$ getent passwd susan uid=1108400007(susan) gid=1108400007(bob) groups=1108400007(susan)
第4章 汎用 LDAP の統合
本章では、Identity サービス (keystone) を汎用 LDAP 環境と統合する方法について説明します。
以下のユースケースでは、Identity サービスが特定の LDAP のユーザーを認証しつつ、Identity サービスデータベース内で承認設定および重要なサービスアカウントを保持します。この手順を実行すると、Identity サービスは、LDAP に読み取り専用でアクセスしてユーザーアカウントの認証を行う一方で、認証されたアカウントに割り当てる権限を引き続き管理するようになります。
4.1. 主要な用語
- 認証: パスワードを使用して、ユーザーが本人であることを検証するプロセス
- 承認: 認証されたユーザーに対して、アクセスしようとしているシステムの適切なパーミッションが付与されていることを確認するプロセス
- ドメイン: Identity サービス内で設定する追加のバックエンドのことを指します。たとえば、Identity サービスは、外部の LDAP 環境内のユーザーを認証するように設定することができます。このように設定されたユーザーの集合は、ドメインとして考えることができます。
4.2. 前提条件
本ガイドのデプロイメント例は、以下を前提としています。
- LDAP サーバーが設定済みで、稼働していること。
- Red Hat OpenStack Platform が設定済みで、稼働していること。
- DNS 名前解決が完全に機能しており、かつ全ホストが適切に登録されていること。
4.3. 影響評価
以下のステップを実行すると、LDAP ユーザーが OpenStack に対して認証を実行して、リソースにアクセスできるようになります。OpenStack のサービスアカウント (keystone、glance など) および承認管理 (パーミッションとロール) は Identity サービスのデータベースに残ります。パーミションとロールは、Identity サービスの管理ツールを使用して LDAP アカウントに割り当てられます。
4.3.1. 高可用性のオプション
この設定により、単一の LDAP に依存するようになるため、Identity サービスがその LDAP サーバーに対して認証できない場合には、プロジェクトユーザーが影響を受けることになります。このリスクを管理するオプションは複数あります。たとえば、keystone が個別の IdM サーバーではなくDNS エイリアスやロードバランシングアプライアンスにクエリーを実行するように設定することが可能です。また、IdM サーバー の 1 つが利用できない場合には、keystone が異なる IdM サーバーにクエリーを実行するように設定することもできます。詳しくは、「高可用性の設定」を参照してください。
4.4. 停止の要件
- LDAP バックエンドを追加するには、Identity サービスを再起動する必要があります。
- keystone v3 に切り替えるには、全ノード上の Compute サービスを再起動する必要があります。
- ユーザーは、LDAP でアカウントが作成されるまでは、Dashboard にアクセスできません。ダウンタイムを短縮するには、この変更の前に十分余裕をもって LDAP アカウントのプレステージを行うことを検討してください。
4.5. ファイアウォールの設定
ファイアウォールが LDAP と OpenStack の間のトラフィックをフィルタリングしている場合には、以下のポートを介したアクセスを許可する必要があります。
送信元 | 送信先 | 種別 | ポート |
---|---|---|---|
OpenStack コントローラーノード |
LDAP サーバー |
LDAPS |
TCP 636 |
4.6. LDAP サーバーの設定
LDAP サーバーで以下のステップを実行して、Identity サービスの統合の準備をします。
1. LDAP ルックアップアカウントを作成します。
このアカウントは、Identity サービスが LDAP サービスにクエリーを実行するのに使用します。このデプロイメント例では、標準のパスワードポリシーの要件に加えて、以下の属性が必要となります。
- First name: OpenStack
- Last name: LDAP
- User name: svc-ldap
作成が完了したら、このアカウントのパスワード期限の設定を確認してください。
2. grp-openstack という名前の OpenStack ユーザーの LDAP グループを作成します。OpenStack Identity でパーミッションを割り当てることができるのは、このグループのメンバーのみです。
3. svc-ldap アカウントのパスワードを設定して、grp-openstack グループに追加します。
4.7. LDAPS 証明書の設定
1. LDAP の環境で、LDAPS 証明書を見つけます。このファイルの場所は、/etc/openldap/ldap.conf で確認することができます。
TLS_CACERT /etc/ipa/ca.crt
2. OpenStack Identity (keystone) を実行しているノードにファイルをコピーします。たとえば、以下のコマンドは、scp を使用して、ca.crt を node.lab.local という名前のコントラーノードにコピーします。
scp /etc/ipa/ca.crt root@node.lab.local:/root/
3. コントローラーノードで、.crt を .pem に変換します。
# openssl x509 -in ca.crt -out ca.pem -outform PEM
4. OpenStack コントローラーに .pem をインストールします。たとえば、Red Hat Enterprise Linux の場合は以下を実行します。
# cp ca.pem /etc/pki/ca-trust/source/anchors/ # update-ca-trust
5. .crt を証明書のディレクトリーにコピーします。
# cp ca.crt /etc/ssl/certs/
4.8. Identity サービスの設定
以下のステップでは、LDAP との統合に備えて、Identity サービスの準備を行います。
4.8.1. keystone v3 へのコマンドラインアクセスの有効化
コマンドラインから Identity サービスドメインを管理するには、keystone v3 にアクセス可能である必要があります。
keystone サービスを実行しているコントローラーから以下の手順を実行します。
1. 既存の環境変数ファイルのコピーを作成します。director ベースのデプロイメントでは、overcloudrc
と呼ばれます。
$ cp overcloudrc overcloudrc-v3
2. 新しい overcloudrc-v3
ファイルを編集します。
-
以下のように、
OS_AUTH_URL
の値を v2.0 から v3 に変更してください。
export OS_AUTH_URL=https://controllerIP:5000/v3/
-
overcloudrc-v3
の一番下に、以下のエントリーを追加します。
export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default
3. source コマンドでこの設定ファイルを読み込み、現在のコマンドラインセッションでこれらのオプションを有効にします。
$ source overcloudrc-v3
4.8.2. コントローラーの設定
keystone サービスを実行しているコントローラーから以下の手順を実行します。
1. SELinux を設定します。
# setsebool -P authlogin_nsswitch_use_ldap=on
2. domains ディレクトリーを作成します。
# mkdir /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/ # chown keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
3. Identity サービスが複数のバックエンドを使用するように設定します。
crudini
using 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 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains # crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf assignment driver sql
Red Hat OpenStack Platform director を使用している場合には、/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf が Puppet で管理されている点を認識する必要があります。このため、カスタムの設定を追加しても、openstack overcloud deploy
プロセスを実行する度に上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。今後の director のリリースでは、デプロイ後のスクリプトを使用して、このような設定を自動的に再適用するための Puppet のパラメーターが追加される予定です。
4. Dashboard で複数のドメインを有効にします。以下の行を /etc/openstack-dashboard/local_settings に追加します。
OPENSTACK_API_VERSIONS = { "identity": 3 } OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'
Red Hat OpenStack Platform director を使用している場合には、/etc/openstack-dashboard/local_settings が Puppet で管理されている点を認識する必要があります。このため、カスタムの設定を追加しても、openstack overcloud deploy
プロセスを実行する度に上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。今後の director のリリースでは、デプロイ後のスクリプトを使用して、このような設定を自動的に再適用するための Puppet のパラメーターが追加される予定です。
httpd を再起動して、設定を適用します。
# systemctl restart httpd
5. 追加のバックエンドを設定します。
a. LDAP 統合のための keystone ドメインを作成します。
新しい keystone ドメインに使用する名前を選択し、ドメインを作成します。たとえば、以下のコマンドは LAB
という名前の keystone ドメインを作成します。
# openstack domain create LAB
このコマンドが使用できない場合には、コマンドラインセッションでの keystone v3 へのアクセスが有効化されているかどうかを確認してください。
b. 設定ファイルを作成します。
LDAP バックエンドを追加するには、/var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf は、前のステップで作成したドメイン名に置き換えます) という名前の新規ファイルに LDAP 設定を入力します。以下の設定例は、実際に使用する LDAP デプロイメントに合わせて編集する必要があります。
[ldap] url = ldaps://ldap.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 = user_allow_create = False user_allow_update = False user_allow_delete = False tls_cacertfile = /etc/ssl/certs/ca.crt [identity] driver = keystone.identity.backends.ldap.Identity
各設定項目について説明します。
設定 | 説明 |
---|---|
|
認証に使用する LDAP サーバー。LDAPS ポート |
|
LDAP クエリーに使用する LDAP 内のアカウント |
|
上記で使用した LDAP アカウントのパスワード (プレーンテキスト形式) |
|
Identity サービスに対して提示するユーザーをフィルタリングすることにより、grp-openstack グループのメンバーのみに Identity サービスで定義されているパーミッションを付与することができます。 |
|
LDAP 内の OpenStack アカウントへのパス |
|
LDAP ユーザーの種別を定義します。LDAP には |
|
ユーザー ID に使用する LDAP 値をマッピングします。 |
|
names に使用する LDAP 値をマッピングします。 |
|
ユーザーのメールアドレスに使用する LDAP 値をマッピングします。 |
|
この値は空白のままにします。 |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
|
keystone では読み取り専用アクセスのみが必要であるため、この値を |
6. 設定ファイルの所有権を keystone ユーザーに変更します。
# chown keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf
7. admin ユーザーにドメインへのアクセス権を付与します。
この手順を実行しても、OpenStack admin アカウントには LDAP のパーミッションは付与されません。この場合には、ドメインという用語は、OpenStack が使用する keystone ドメインのことを指しています。
a. LAB ドメインの ID
を取得します。
# openstack domain show LAB +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | enabled | True | | id | 6800b0496429431ab1c4efbb3fe810d4 | | name | LAB | +---------+----------------------------------+
b. admin ユーザーの ID
の値を取得します。
# openstack user list --domain default | grep admin | 3d75388d351846c6a880e53b2508172a | admin |
c. admin ロールの ID
の値を取得します。
# openstack role list +----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
d. 返されたドメインおよび管理 ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。
# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
8. keystone サービスを再起動して、変更を適用します。
# sudo docker exec -it keystone pkill -HUP -f keystone
9. コマンドで keystone ドメイン名を指定して、LDAP ドメイン内のユーザー一覧を確認します。
# openstack user list --domain LAB
10. ローカルの keystone データベース内のサービスアカウントを確認します。
# openstack user list --domain default
4.8.3. Compute が keystone v3 を使用するようにするための設定
Compute はデフォルトで keystone v2.0 を使用するように設定されているので、マルチドメイン機能を使用するためには、keystone v3 を使用するように設定する必要があります。
1. 各コンピュートノードとコントローラーで keystone_authtoken
値を変更します。
# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
2. コントローラーでサービスを再起動して、変更を適用します。
# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service # sudo docker exec -it keystone pkill -HUP -f keystone
3. 各コンピュートノードでサービスを再起動して、変更を適用します。
# systemctl restart openstack-nova-compute.service
4.8.4. Block Storage が keystone v3 を使用するようにするための設定
keystone v3 に対して認証を実行するには、Block Storage (cinder) を設定する必要もあります。
/etc/cinder/cinder.conf を編集します。
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
-
auth_uri
のcontrollerIP
の箇所をコントローラーの IP アドレスに置き換えます。デプロイメントにコントローラーが複数ある場合には、コントローラーの IP アドレスの代わりに keystone エンドポイントの仮想 IP アドレスを使用すべきです。
-
全コントローラーで
cinder-api
を再起動します。# systemctl restart openstack-cinder-api
全コントローラーで
cinder-scheduler
を再起動します。# systemctl restart openstack-cinder-scheduler
cinder-volume
を再起動します (1 台のコントローラーでのみ)。# pcs resource restart openstack-cinder-volume
4.8.5. LDAP ユーザーによるプロジェクトへのアクセスの許可
grp-openstack LDAP グループのメンバーである LDAP ユーザーには、Dashboard 内のプロジェクトにログインするパーミッションを付与することができます。
1. LDAP ユーザーの一覧を取得します。
# openstack user list --domain LAB +------------------------------------------------------------------+----------------+ | ID | Name | +------------------------------------------------------------------+----------------+ | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1 | | 12c062fLDAP5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | 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 は LDAP のユーザー名とパスワードを入力してから、ドメインのフィールドにも LAB
と入力すると Dashboard にログインすることができます。
ユーザーに「Error: Unable to retrieve container list.」というエラーメッセージが表示され、コンテナーの管理が可能であることが想定されている場合には、SwiftOperator ロールに追加する必要があります。
4.9. ドメインタブへのアクセスの許可
admin
ユーザーが ドメイン
タブを見えるようにするには、そのユーザーを default
ドメインで admin
ロールに割り当てる必要があります。
admin
ユーザーの UUID を確認します。$ openstack user list | grep admin | a6a8adb6356f4a879f079485dad1321b | admin |
default
ドメインのadmin
ロールをadmin
ユーザーに追加します。$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
その結果、
admin
ユーザーにDomain
タブが見えるようになります。
4.10. 新規プロジェクトの作成
上記の統合ステップが完了した後に新規プロジェクトを作成する場合には、Default
ドメインと、自分で作成した keystone ドメインのどちらに作成するかを決定する必要があります。これは、ワークフローとユーザーアカウントの管理方法を考慮して決定することができます。Default
ドメインは、サービスアカウントと admin
プロジェクトに使用する内部ドメインとして考えることができるので、AD でバッキングされているユーザーを異なる keystone ドメインに内に配置することは理にかなっています。これは、LDAP ユーザーが管理されているのと全く同じ keystone ドメインである必要はありません。また、分離の目的で複数の keystone ドメインを使用することも可能です。
4.10.1. Dashboard へのログインプロセスの変更
Identity サービスに複数のドメインを設定すると、Dashboard のログインメージに新しい ドメイン フィールドが有効になります。
ユーザーは、ログイン認証情報にマッチするドメインを入力する必要があります。このフィールドには、keystone で提示されるドメインの 1 つを手動で入力する必要があります。利用可能なエントリーを表示するには、openstack コマンドを使用します。
以下の例では、LDAP アカウントには LAB
ドメインを指定する必要があります。admin のような組み込みの keystone アカウントには、ドメインに Default
を指定する必要があります。
# openstack domain list +----------------------------------+---------+---------+----------------------------------------------------------------------+ | ID | Name | Enabled | Description | +----------------------------------+---------+---------+----------------------------------------------------------------------+ | 6800b0496429431ab1c4efbb3fe810d4 | LAB | True | | | default | Default | True | Owns users and tenants (i.e. projects) available on Identity API v2. | +----------------------------------+---------+---------+----------------------------------------------------------------------+
4.10.2. コマンドラインへの変更
特定のコマンドでは、対象のドメインを指定する必要がある場合があります。たとえば、以下のコマンドに --domain LAB
を追加すると、LAB ドメイン内のユーザー (grp-openstack グループのメンバー) が返されます。
# openstack user list --domain LAB
--domain Default
を追加すると、組み込みの keystone アカウントが返されます。
# openstack user list --domain Default
4.10.3. LDAP 統合のテスト
以下の手順では、Dashboard の機能へのユーザーアクセスをテストして、LDAP の統合を検証します。
1. LDAP にテストユーザーを作成し、そのユーザーを grp-openstack
LDAP グループに追加します。
2. テストユーザーを demo
テナントの _member_
ロールに追加します。
3. LDAP テストユーザーの認証情報を使用して Dashboard にログインします。
4. 各タブをクリックし、エラーメッセージなしに正常に表示されているかどうかを確認します。
5. Dashboard を使用してテストインスタンスをビルドします。
上記の手順で問題が発生した場合には、組み込みの admin アカウントでステップ 3 から 5 までを実行してください。正常に実行できた場合には、OpenStack が想定通りに機能していることが実証されるので、問題は LDAP と Identity の統合設定の間のどこかにあることになります。「トラブルシューティング」を参照してください。
4.11. 高可用性の設定
keystone v3 が有効化されている場合には、ドメインの設定ファイルに複数の LDAP サーバーをリストして、この設定を高可用性にすることが可能です。
1. 2 番目のサーバーを url
エントリーに追加します。たとえば、keystone.LAB.conf ファイル内の url
設定を更新すると、Identity サービスは全クエリートラフィックをリスト内で 1 番目の LDAP サーバーである ldap.lab.local に送信します。
url = ldaps://ldap.lab.local,ldaps://ldap2.lab.local
ldap.lab.local が利用できないためにクエリーが失敗した場合には、Identity サービスはリストに記載されている次のサーバー ldap2.lab.local にクエリーの送信を試みます。この設定では、ラウンドロビン式にはクエリーが実行されないので、ロードバランスのソリューションとしては考慮できない点に注意してください。
2. /etc/openldap/ldap.conf でネットワークのタイムアウトを設定します。
NETWORK_TIMEOUT 2
また、コントローラーと LDAP サーバーの間でファイアウォールが設定されている場合には、LDAP サーバーがダイアログを表示せずにコントローラーからのパケットを破棄してしまわないように設定すべきです。このように設定すると、python-keystoneclient が機能停止を適切に検知して、リスト内の次の LDAP サーバーに要求をリダイレクトすることができます。
クエリーがリストの第 2 の LDAP サーバーに転送される間に接続の遅延が発生する可能性があります。これは、第 2 のサーバーへの接続を試みるには、第 1 のサーバーがタイムアウトになる必要があるためです。
4.12. 非管理ユーザー用の RC ファイルの作成
非管理ユーザー用の RC ファイルを作成する必要がある場合があります。以下に例を示します。
$ cat overcloudrc-v3-user1 # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_USERNAME=user1 export NOVA_VERSION=1.1 export OS_PROJECT_NAME=demo export OS_PASSWORD=RedactedComplexPassword export OS_NO_CACHE=True export COMPUTE_API_VERSION=1.1 export no_proxy=,10.0.0.5,192.168.2.11 export OS_CLOUDNAME=overcloud export OS_AUTH_URL=https://10.0.0.5:5000/v3 export OS_AUTH_TYPE=password export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available" export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=LAB
4.13. トラブルシューティング
4.13.1. LDAP 接続のテスト
LDAP サーバーに対してテストクエリーをリモートで実行するには、ldapsearch を使用します。クエリーが成功した場合には、ネットワーク接続が機能しており、LDAP サービスが稼働中であることを確認できます。以下の例では、テストクエリーはサーバー ldap.lab.local のポート 636 に対して実行されます。
# ldapsearch -D "cn=directory manager" -H ldaps://ldap.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword
ldapsearch は、openldap-clients パッケージに含まれています。このパッケージは、# yum install openldap-clients
のコマンドを実行するとインストールすることができます。
4.13.2. ポートアクセスのテスト
nc を使用して、LDAPS ポート (636) がリモートでアクセス可能であることを確認します。この例では、サーバー ldap.lab.local に対してプローブを実行します。ctrl-c を押してプロンプトを終了します。
# nc -v ldap.lab.local 636 Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 192.168.200.10:636. ^C
接続を確立できなかった場合には、ファイアウォールの設定に問題がある可能性があります。
第5章 director でのドメイン固有の LDAP バックエンドの使用
Red Hat OpenStack Platform director では、keystone が 1 つまたは複数の LDAP バックエンドを使用するように設定することができます。この方法では、keystone ドメインごとに別々の LDAP バックエンドが作成されます。
5.1. 設定オプションの指定
Red Hat OpenStack Platform director を使用したデプロイメントの場合には、Heat テンプレートで KeystoneLDAPDomainEnable
フラグを true
に設定する必要があります。その結果、keystone で domain_specific_drivers_enabled
オプションが設定されます (identity
設定グループ内)。
ドメイン設定ファイルのデフォルトのディレクトリーは /etc/keystone/domains/
に設定されています。keystone::domain_config_directory
hiera キーを使用して環境ファイル内に ExtraConfig
パラメーターを追加して必要なパスを設定することによってオーバーライドすることができます。
LDAP バックエンドの設定の仕様を追加する必要もあります。これは、tripleo-heat-templates
の KeystoneLDAPBackendConfigs
パラメーターを使用して設定します。これで、必要な LDAP オプションを指定することができるようになります。利用可能なオプションについての詳しい情報は、『Configuration Reference Guide』を参照してください。
5.2. director デプロイメントの設定
Heat テンプレートには、現在既知の問題があり、keystone.yaml
に keystone_domain_confg
タグが含まれていません。この問題の回避策と詳しい情報は、https://bugzilla.redhat.com/show_bug.cgi?id=1519057 を参照してください。
keystone_domain_specific_ldap_backend.yaml
環境ファイルのコピーを作成します。$ cp /usr/share/openstack-tripleo-heat-templates/environments/services/keystone_domain_specific_ldap_backend.yaml /home/stack/templates/
/home/stack/templates/keystone_domain_specific_ldap_backend.yaml
環境ファイルを編集して、デプロイメントに適した値を設定します。たとえば、以下のエントリーは、testdomain
という名前の keystone ドメイン向けの LDAP 設定を作成しています。parameter_defaults: KeystoneLDAPDomainEnable: true KeystoneLDAPBackendConfigs: testdomain: url: ldaps://192.0.2.250 user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword suffix: dc=director,dc=example,dc=com user_tree_dn: ou=Users,dc=director,dc=example,dc=com user_filter: "(memberOf=cn=OSuser,ou=Groups,dc=director,dc=example,dc=com)" user_objectclass: person user_id_attribute: cn user_allow_create: false user_allow_update: false user_allow_delete: false
また、複数のドメインを指定するように環境ファイルを設定することも可能です。以下に例を示します。
KeystoneLDAPBackendConfigs: domain1: url: ldaps://domain1.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ... domain2: url: ldaps://domain2.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ...
これにより、
domain1
とdomain2
という名前の 2 つのドメインが指定され、各ドメインには、異なる LDAP ドメインが独自の設定で適用されます。
現在、既知の問題 (BZ 1519057) があります。