Identity サービスとの統合


Red Hat OpenStack Platform 8

Active Directory、IdM、または汎用 LDAP を外部認証バックエンドとして使用する方法

OpenStack Documentation Team

概要

Active Directory、IdM、または汎用 LDAP を外部認証バックエンドとして使用する方法

はじめに

Identity サービス(コード名 keystone)は Red Hat OpenStack Platform 8 の認証と承認を提供します。

このガイドでは、Microsoft Active Directory Domain Service (AD DS)および Red Hat Identity Management (IdM)に 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 を使用していること。
重要

Red Hat OpenStack Platform のこのバージョンでは、マルチドメインダッシュボード設定はサポートされません。本書では、1 つのドメインのダッシュボード設定についてのみ説明しています。

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 の間のトラフィックをフィルタリングしている場合には、以下のポートを介したアクセスを許可する必要があります。

Expand
ソース送信先タイプポート

OpenStack コントローラーノード

Active Directory Domain Controller

LDAPS

TCP 636

1.6. Active Directory ドメインサービスの設定

本項では、Active Directory の管理者が完了する必要のあるタスクについて説明します。

Expand
表1.1 設定手順

タスク

詳細

サービスアカウントの作成

サービスアカウントの名前は、svc-ldap など、サービスアカウントの命名規則に従って指定することができます。これは、通常のドメインユーザーアカウントを指定できます。管理者権限は必要ありません。

ユーザーグループの作成

OpenStack へのアクセス権限がユーザーに必要な場合は、このグループに所属する必要があります。ユーザーグループの名前は、grp-openstack など、ユーザーグループの命名規則に従って指定することができます。このグループのメンバーが、Dashuboard 内の プロジェクト グループのメンバーでもある場合には、そのプロジェクトへのアクセス権が付与されます。

プロジェクトグループの作成

OpenStack の各プロジェクトには、対応する AD グループが必要です。たとえば、grp-openstack-demogrp-openstack-admin などがあります。

サービスアカウントの設定

サービスアカウント svc-ldap は、grp-openstack グループのメンバーである必要があります。

LDAPS 公開鍵のエクスポート

公開鍵 (秘密鍵ではない) は、DER-encoded x509 .cer ファイルの形式でエクスポートします。

OpenStack 管理者へのキーの送信

OpenStack の管理者は、このキーを使用して、OpenStack および Active Directory の LDAPS 通信を暗号化します。

AD DS ドメインの NetBIOS 名の取得。

OpenStack 管理者は、Keystone ドメインにこの名前を使用して、複数の環境間で一貫性のあるドメイン名を指定することができます。

たとえば、以下の手順では、Active Directory Domain Controller で実行する 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'
Copy to Clipboard Toggle word wrap

2.このアカウントのパスワードを設定し、有効にします。AD ドメインのパスワードの複雑さの要件を満たすパスワードを指定するように要求されます。

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
Copy to Clipboard Toggle word wrap

3.grp-openstack という名前の OpenStack ユーザーグループを作成します。

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap

5.svc-ldap ユーザーを grp-openstack グループに追加します。

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
Copy to Clipboard Toggle word wrap

6.AD Domain Controller から Certificates MMC を使用して、DER でエンコードされた x509 .cer ファイルとして LDAPS 証明書の(秘密鍵ではなく)公開鍵 をエクスポートします。このファイルを OpenStack 管理者に送信します。

7. AD DS ドメインの NetBIOS 名の取得。

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB
Copy to Clipboard Toggle word wrap

この値を 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
Copy to Clipboard Toggle word wrap

2. OpenStack コントローラーに .pem をインストールします。たとえば、Red Hat Enterprise Linux の場合は以下を実行します。

# cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
Copy to Clipboard Toggle word wrap

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/
Copy to Clipboard Toggle word wrap

1.8. Identity サービスの設定

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

1.8.1. keystone v3 へのコマンドラインへのアクセスを有効にする

コマンドラインから Identity サービスドメインを管理するには、keystone v3 へのアクセスを有効にする必要があります。

keystone サービスを実行しているコントローラーから、この手順を実行します。

1.既存の環境変数ファイルのコピーを作成します。director ベースのデプロイメントでは、overcloudrc と呼ばれます。

$ cp overcloudrc overcloudrc-v3
Copy to Clipboard Toggle word wrap

2. 新しい overcloudrc-v3 ファイルを編集します。

  • OS_AUTH_URLv2.0 から v 3 に変更します。以下に例を示します。
export OS_AUTH_URL=https://controllerIP:5000/v3/
Copy to Clipboard Toggle word wrap
  • 以下のエントリーを overcloudrc-v3 の下部に追加します。
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
Copy to Clipboard Toggle word wrap

3.ファイルを調達して、現在のコマンドラインセッションで以下のオプションを有効にします。

$ source overcloudrc-v3
Copy to Clipboard Toggle word wrap

1.8.2. コントローラーの設定

keystone サービスを実行しているコントローラーから、この手順を実行します。複数のコントローラーで HA 環境を実行している場合には、コントローラーごとに以下の手順を実行する必要があります。

1.SELinux を設定します。

# setsebool -P authlogin_nsswitch_use_ldap=on
Copy to Clipboard Toggle word wrap

出力には、以下のようなメッセージが含まれている場合がありますが、これは無視できます。

Full path required for exclude: net:[4026532245].
Copy to Clipboard Toggle word wrap

2. domains ディレクトリーを作成します。

# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/
Copy to Clipboard Toggle word wrap

3.Identity サービスが複数のバックエンドを使用するように設定します。

注記

yum install crudini のコマンドを実行して crudini をインストールする必要がある場合があります。

# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql
Copy to Clipboard Toggle word wrap
注記

Red Hat OpenStack Platform director を使用している場合は、/etc/keystone/keystone.conf が Puppet によって管理されていることを認識する必要があります。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。director の今後のリリースでは、デプロイ後のスクリプトを使用してこれらの設定を自動的に適用できるようにする Puppet パラメーターが含まれる予定です。

4.追加のバックエンドを設定します。

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

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

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

# openstack domain create LAB
Copy to Clipboard Toggle word wrap
注記

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

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

AD DS バックエンドを追加するには、/etc/keystone/domains/keystone.LAB.conf という名前の新規ファイルに LDAP 設定を入力します( LAB は、前のステップで取得した NetBIOS 名に置き換えます)。以下の設定例は、実際に使用する 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
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
Copy to Clipboard Toggle word wrap

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

Expand
設定説明

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 サービスが無視する必要のあるユーザー属性を定義します。

user_allow_create

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

user_allow_update

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

user_allow_delete

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

group_objectclass

groups に使用する AD 値をマッピングします。

group_tree_dn

そのユーザーグループを含む 組織単位 (OU)。

group_filter

Identity サービスに提示するグループをフィルタリングします。

group_id_attribute

グループ ID に使用する AD 値をマッピングします。

group_name_attribute

グループ名に使用する AD 値をマッピングします。

group_allow_create

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

group_allow_update

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

group_allow_delete

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

use_tls

TLS を使用するかどうかを定義します。STARTTLS ではなく LDAPS で暗号化する場合には、無効にする必要があります。

tls_cacertfile

.crt 証明書ファイルへのパスを指定します。

query_scope

grp-openstack グループに所属するユーザーを特定する場合に、Identity サービスがネスト化された子 OU 内での検索ができるように設定します。

chase_referrals

false に設定します。この設定により python-ldap が匿名のアクセスによる全参照を追跡しないようにします。

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

# chown keystone /etc/keystone/domains/keystone.LAB.conf
Copy to Clipboard Toggle word wrap

7. ログインページで LAB keystone ドメインを使用するように Dashboard を設定します。/etc/openstack-dashboard/local_settings に以下の行を追加します。

重要

Red Hat OpenStack Platform のこのバージョンでは、マルチドメインダッシュボード設定はサポートされません。本書では、1 つのドメインのダッシュボード設定についてのみ説明しています。

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
Copy to Clipboard Toggle word wrap
注記

Red Hat OpenStack Platform director を使用している場合は、/etc/openstack-dashboard/local_settings が Puppet によって管理されていることを認識する必要があります。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。director の今後のリリースでは、デプロイ後のスクリプトを使用してこれらの設定を自動的に適用できるようにする Puppet パラメーターが含まれる予定です。

8. httpd サービスを再起動して変更を適用します。

# systemctl restart httpd.service
Copy to Clipboard Toggle word wrap

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

注記

この手順を実行しても、OpenStack admin アカウントには実際の AD DS ドメインに対するパーミッションは付与されない点を念頭に置いてください。ここで使われるドメインという用語は、OpenStack が使用する keystone ドメインのことを指しています。

a.LAB ドメインの ID を取得します。

# openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+
Copy to Clipboard Toggle word wrap

b.admin ユーザーの ID の値を取得します。

# openstack user list --domain default | grep admin
| 3d75388d351846c6a880e53b2508172a | admin      |
Copy to Clipboard Toggle word wrap

c.admin ロールの ID の値を取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
Copy to Clipboard Toggle word wrap

d.返されたドメインおよび admin の ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。

# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
Copy to Clipboard Toggle word wrap

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

注記

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

# openstack user list --domain LAB
Copy to Clipboard Toggle word wrap

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

# openstack user list --domain default
Copy to Clipboard Toggle word wrap

1.8.3. keystone v3 を使用するように Compute を設定する

Compute はデフォルトで keystone v2.0 を使用するので、マルチドメイン機能を使用するには keystone v3 を使用するように設定する必要があります。

1.各コンピュートノードで keystone_authtoken の値を調整します。

# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

3.各コンピュートノードでこのサービスを再起動して、変更を適用します。

# systemctl restart openstack-nova-compute.service
Copy to Clipboard Toggle word wrap

1.8.4. Block Storage が keystone v3 を使用するように設定する手順

keystone v3 に対して認証するには、Block Storage (cinder)も設定する必要があります。

  1. /etc/cinder/cinder.conf で以下を行います。

    [keystone_authtoken]
    auth_uri = https://controllerIP:5000/v3
    auth_version = v3
    Copy to Clipboard Toggle word wrap
    • auth_uri - controllerIP をコントローラーの IP アドレスに置き換えます。デプロイメントに複数のコントローラーがある場合には、コントローラー IP の代わりに keystone エンドポイントの仮想 IP を使用する必要があります。

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  |
+------------------------------------------------------------------+---------------------+
Copy to Clipboard Toggle word wrap

2. ロールのリストを取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin |
| 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
| d3570730eb4b4780a7fed97eba197e1b | SwiftOperator |
+----------------------------------+---------------+
Copy to Clipboard Toggle word wrap

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

# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8  _member_
Copy to Clipboard Toggle word wrap

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

注記

ユーザーに 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          |
+------------------------------------------------------------------+----------------+
Copy to Clipboard Toggle word wrap

2. ロールのリストを取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
Copy to Clipboard Toggle word wrap

3.リスト表示されたロールの中から 1 つまたは複数のロールをユーザーに追加して、プロジェクトへのアクセス権を付与します。たとえば、user1demo プロジェクトの一般ユーザーにするには、member ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
Copy to Clipboard Toggle word wrap

または、user1demo プロジェクトの管理ユーザーにするには、admin ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
Copy to Clipboard Toggle word wrap

その結果、user1 は AD DS のユーザー名とパスワードを入力して Dashboard にログインすることができます。

注記

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

1.9. ドメインタブへのアクセスの許可

admin ユーザーが Domain タブを見えるようにするには、そのユーザーを default ドメインで admin ロールに割り当てる必要があります。

  1. admin ユーザーの UUID を確認します。

    $ openstack user list | grep admin
    | a6a8adb6356f4a879f079485dad1321b | admin      |
    Copy to Clipboard Toggle word wrap
  2. default ドメインの admin ロールを admin ユーザーに追加します。

    $ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
    Copy to Clipboard Toggle word wrap

    その結果、admin ユーザーに Domain タブが見えるようになります。

1.10. 新規プロジェクトの作成

上記の統合ステップが完了した後に新規プロジェクトを作成する場合には、Default ドメインと、自分で作成した keystone ドメインのどちらに作成するかを決定する必要があります。これは、ワークフローとユーザーアカウントの管理方法を考慮して決定することができます。Default ドメインは、サービスアカウントと admin プロジェクトの管理に使用する内部ドメインとして考えることができます。また、分離の目的で、AD でバッキングされているユーザーを異なる keystone ドメインで使用することも可能です。

1.11. コマンドラインへの変更

特定のコマンドでは、対象のドメインを指定する必要がある場合があります。たとえば、以下のコマンドに --domain LAB を追加すると、LAB ドメイン内のユーザー (grp-openstack グループのメンバー) が返されます。

# openstack user list --domain LAB
Copy to Clipboard Toggle word wrap

--domain Default を追加すると、組み込みの keystone アカウントが返されます。

# openstack user list --domain Default
Copy to Clipboard Toggle word wrap

1.12. 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.13. 高可用性の設定

keystone v3 が有効化されている場合には、ドメインの設定ファイルに複数の AD Domain Controller をリストして、この設定を高可用性にすることが可能です。

1.2 番目のサーバーを url エントリーに追加します。たとえば、keystone.LAB.conf ファイル内の url 設定を更新すると、Identity サービスは全クエリートラフィックをリスト内で 1 番目の Domain Controller である addc.lab.local に送信します。

url =  ldaps://addc.lab.local,ldaps://addc2.lab.local
Copy to Clipboard Toggle word wrap

addc.lab.local が利用できないためにクエリーが失敗した場合、Identity サービスは一覧の次のサーバー addc2.lab.local にクエリーの送信を試みます。この設定では、ラウンドロビン式にはクエリーが実行されないので、ロードバランスのソリューションとしては考慮できない点に注意してください。

2./etc/openldap/ldap.conf でネットワークのタイムアウトを設定します。

NETWORK_TIMEOUT 2
Copy to Clipboard Toggle word wrap

また、コントローラーとドメインコントローラーの間でファイアウォールが設定されている場合には、ドメインコントローラーがダイアログを表示せずにコントローラーからのパケットを破棄してしまわないように設定する必要があります。このように設定すると、python-keystoneclient が機能停止を適切に検出して、リスト内の次のドメインコントローラーに要求をリダイレクトすることができます。

注記

クエリーがリストの第 2 の LDAP サーバーにリダイレクトされる間に接続の遅延が発生する可能性があります。これは、第 2 のサーバーへの接続を試みるには、第 1 のサーバーがタイムアウトになる必要があるためです。

1.14. 非管理ユーザー用の 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
Copy to Clipboard Toggle word wrap

1.15. トラブルシューティング

1.15.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
Copy to Clipboard Toggle word wrap
注記

ldapsearch は、openldap-clients パッケージに含まれています。このパッケージは、# yum install openldap-clients のコマンドを実行するとインストールすることができます。

1.15.2. 証明書トラストの設定テスト

ldapsearch のテストの際に Peer's Certificate issuer is not recognized. というエラーを受け取った場合には、TLS_CACERTDIR パスが正しく設定されていることを確認してください。以下に例を示します。

  • /etc/openldap/ldap.conf
TLS_CACERTDIR /etc/openldap/certs
Copy to Clipboard Toggle word wrap
注記

一時的な回避策として、証明書の検証を無効にすることを検討してください。

この設定は、永続的には使用しないでください。

  • /etc/openldap/ldap.conf
TLS_REQCERT allow
Copy to Clipboard Toggle word wrap

この値を設定した後に ldapsearch クエリーが機能した場合には、証明書トラストが正しく設定されているかどうかを確認する必要があります。

1.15.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
Copy to Clipboard Toggle word wrap

接続を確立できなかった場合には、ファイアウォールの設定に問題がある可能性があります。

第2章 Identity Management の統合

本章では、Identity サービス (keystone) を Red Hat Identity Management と統合する方法について説明します。

以下のユースケースでは、Identity サービスが特定の Red Hat Identity Management (IdM) のユーザーを認証しつつ、Identity サービスデータベース内で承認設定および重要なサービスアカウントを保持します。
この手順を実行すると、Identity サービスは、IdM に読み取り専用でアクセスしてユーザーアカウントの認証を行う一方で、認証されたアカウントに割り当てる権限を引き続き管理するようになります。

2.1. 主要な用語

  • 認証: パスワードを使用して、ユーザーが本人であることを検証するプロセス。
  • 承認: 認証されたユーザーに対して、アクセスしようとしているシステムの適切なパーミッションが付与されていることを確認するプロセス。
  • ドメイン: Identity サービス内で設定する追加のバックエンド。たとえば、Identity サービスは、外部の IdM 環境内のユーザーを認証するように設定することができます。このように設定されたユーザーの集合は、ドメイン として考えることができます。

2.2. 前提条件

本ガイドのデプロイメント例は、以下を前提としています。

  • Red Hat Identity Management が設定済みで、稼働していること。
  • Red Hat OpenStack Platform が設定済みで、稼働していること。
  • DNS 名前解決が完全に機能しており、かつ全ホストが適切に登録されていること。
重要

Red Hat OpenStack Platform のこのバージョンでは、マルチドメインダッシュボード設定はサポートされません。本書では、1 つのドメインのダッシュボード設定についてのみ説明しています。

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 の間のトラフィックをフィルタリングしている場合には、以下のポートを介したアクセスを許可する必要があります。

Expand
ソース送信先タイプポート

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
Copy to Clipboard Toggle word wrap
注記

作成が完了したら、このアカウントのパスワード期限の設定を確認してください。

2.grp-openstack という名前の OpenStack ユーザーグループを作成します。OpenStack Identity でパーミッションを割り当てることができるのは、このグループのメンバーのみです。

# ipa group-add --desc="OpenStack Users" grp-openstack
Copy to Clipboard Toggle word wrap

3.svc-ldap アカウントのパスワードを設定して、grp-openstack グループに追加します。

# ipa passwd svc-ldap
# ipa group-add-member --users=svc-ldap grp-openstack
Copy to Clipboard Toggle word wrap

2.7. LDAPS 証明書の設定

1.IdM の環境で、LDAPS 証明書を見つけます。このファイルの場所は、/etc/openldap/ldap.conf で確認することができます。

TLS_CACERT /etc/ipa/ca.crt
Copy to Clipboard Toggle word wrap

2.OpenStack Identity (keystone)を実行中のノードにファイルをコピーします。たとえば、以下のコマンドは scp を使用して ca.crt を node.lab.local という名前のコントローラーノードにコピーします。

scp /etc/ipa/ca.crt root@node.lab.local:/root/
Copy to Clipboard Toggle word wrap

3.コントローラーノードで .crt を .pem に変換します。

# openssl x509 -in ca.crt -out ca.pem -outform PEM
Copy to Clipboard Toggle word wrap

4.OpenStack コントローラーに .pem をインストールします。たとえば、Red Hat Enterprise Linux の場合は以下を実行します。

# cp ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
Copy to Clipboard Toggle word wrap

5..crt を証明書のディレクトリーにコピーします。

# cp ca.crt /etc/ssl/certs/
Copy to Clipboard Toggle word wrap

2.8. Identity サービスの設定

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

2.8.1. keystone v3 へのコマンドラインへのアクセスを有効にする

コマンドラインから Identity サービスドメインを管理するには、keystone v3 へのアクセスを有効にする必要があります。

keystone サービスを実行しているコントローラーから、この手順を実行します。

1.既存の環境変数ファイルのコピーを作成します。director ベースのデプロイメントでは、overcloudrc と呼ばれます。

$ cp overcloudrc overcloudrc-v3
Copy to Clipboard Toggle word wrap

2. 新しい overcloudrc-v3 ファイルを編集します。

  • OS_AUTH_URLv2.0 から v 3 に変更します。以下に例を示します。
export OS_AUTH_URL=https://controllerIP:5000/v3/
Copy to Clipboard Toggle word wrap
  • 以下のエントリーを overcloudrc-v3 の下部に追加します。
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
Copy to Clipboard Toggle word wrap

3.ファイルを調達して、現在のコマンドラインセッションで以下のオプションを有効にします。

$ source overcloudrc-v3
Copy to Clipboard Toggle word wrap

2.8.2. コントローラーの設定

keystone サービスを実行しているコントローラーから、以下の手順を実行します。

1.SELinux を設定します。

# setsebool -P authlogin_nsswitch_use_ldap=on
Copy to Clipboard Toggle word wrap

2.domains ディレクトリーを作成します。

# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/
Copy to Clipboard Toggle word wrap

3.Identity サービスが複数のバックエンドを使用するように設定します。

注記

yum install crudini のコマンドを実行して crudini をインストールする必要がある場合があります。

# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql
Copy to Clipboard Toggle word wrap
注記

Red Hat OpenStack Platform director を使用している場合は、/etc/keystone/keystone.conf が Puppet によって管理されていることを認識する必要があります。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。director の今後のリリースでは、デプロイ後のスクリプトを使用してこれらの設定を自動的に適用できるようにする Puppet パラメーターが含まれる予定です。

4.追加のバックエンドを設定します。

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

# openstack domain create LAB
Copy to Clipboard Toggle word wrap
注記

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

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

IdM バックエンドを追加するには、/etc/keystone/domains/keystone.LAB.conf という名前の新規ファイルに LDAP 設定を入力します( LAB は、前のステップで作成したドメイン名に置き換えます)。以下の設定例は、実際に使用する 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
Copy to Clipboard Toggle word wrap

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

Expand
設定説明

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

この値は空白のままにします。

user_allow_create

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

user_allow_update

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

user_allow_delete

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

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

# chown keystone /etc/keystone/domains/keystone.LAB.conf
Copy to Clipboard Toggle word wrap

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

注記

この手順を実行しても、OpenStack admin アカウントには IdM のパーミッションは付与されません。ここで使われるドメインという用語は、OpenStack が使用する keystone ドメインのことを指しています。

a.LAB ドメインの ID を取得します。

# openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+
Copy to Clipboard Toggle word wrap

b.admin ユーザーの ID の値を取得します。

# openstack user list --domain default | grep admin

| 3d75388d351846c6a880e53b2508172a | admin      |
Copy to Clipboard Toggle word wrap

c.admin ロールの ID の値を取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
Copy to Clipboard Toggle word wrap

d.返されたドメインおよび admin の ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。

# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
Copy to Clipboard Toggle word wrap

7. ログインページで LAB keystone ドメインを使用するように Dashboard を設定します。/etc/openstack-dashboard/local_settings に以下の行を追加します。

重要

Red Hat OpenStack Platform のこのバージョンでは、マルチドメインダッシュボード設定はサポートされません。本書では、1 つのドメインのダッシュボード設定についてのみ説明しています。

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
Copy to Clipboard Toggle word wrap
注記

Red Hat OpenStack Platform director を使用している場合は、/etc/openstack-dashboard/local_settings が Puppet によって管理されていることを認識する必要があります。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。director の今後のリリースでは、デプロイ後のスクリプトを使用してこれらの設定を自動的に適用できるようにする Puppet パラメーターが含まれる予定です。

8. httpd サービスを再起動して変更を適用します。

# systemctl restart httpd.service
Copy to Clipboard Toggle word wrap

9.コマンドで keystone ドメイン名を指定して、IdM ドメイン内のユーザーリストを確認します。

# openstack user list --domain LAB
Copy to Clipboard Toggle word wrap

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

# openstack user list --domain default
Copy to Clipboard Toggle word wrap

2.8.3. keystone v3 を使用するように Compute を設定する

Compute はデフォルトで keystone v2.0 を使用するので、マルチドメイン機能を使用するには keystone v3 を使用するように設定する必要があります。

1.各コンピュートノードで keystone_authtoken の値を調整します。

# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

3.各コンピュートノードでこのサービスを再起動して、変更を適用します。

# systemctl restart openstack-nova-compute.service
Copy to Clipboard Toggle word wrap

2.8.4. Block Storage が keystone v3 を使用するように設定する手順

keystone v3 に対して認証するには、Block Storage (cinder)も設定する必要があります。

  1. /etc/cinder/cinder.conf で以下を行います。

    [keystone_authtoken]
    auth_uri = https://controllerIP:5000/v3
    auth_version = v3
    Copy to Clipboard Toggle word wrap
    • auth_uri - controllerIP をコントローラーの IP アドレスに置き換えます。デプロイメントに複数のコントローラーがある場合には、コントローラー IP の代わりに keystone エンドポイントの仮想 IP を使用する必要があります。

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          |
+------------------------------------------------------------------+----------------+
Copy to Clipboard Toggle word wrap

2. ロールのリストを取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
Copy to Clipboard Toggle word wrap

3.リスト表示されたロールの中から 1 つまたは複数のロールをユーザーに追加して、プロジェクトへのアクセス権を付与します。たとえば、user1demo プロジェクトの一般ユーザーにするには、それらを _member_ ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
Copy to Clipboard Toggle word wrap

または、user1demo プロジェクトの管理ユーザーにするには、admin ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
Copy to Clipboard Toggle word wrap

その結果、user1 は IdM のユーザー名とパスワードを入力して Dashboard にログインすることができます。

注記

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

2.9. ドメインタブへのアクセスの許可

admin ユーザーが Domain タブを見えるようにするには、そのユーザーを default ドメインで admin ロールに割り当てる必要があります。

  1. admin ユーザーの UUID を確認します。

    $ openstack user list | grep admin
    | a6a8adb6356f4a879f079485dad1321b | admin      |
    Copy to Clipboard Toggle word wrap
  2. default ドメインの admin ロールを admin ユーザーに追加します。

    $ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
    Copy to Clipboard Toggle word wrap

    その結果、admin ユーザーに Domain タブが見えるようになります。

2.10. 新規プロジェクトの作成

上記の統合ステップが完了した後に新規プロジェクトを作成する場合には、Default ドメインと、自分で作成した keystone ドメインのどちらに作成するかを決定する必要があります。これは、ワークフローとユーザーアカウントの管理方法を考慮して決定することができます。Default ドメインは、サービスアカウントと admin プロジェクトに使用する内部ドメインとして考えることができるので、AD でバッキングされているユーザーを異なる keystone ドメインに内に配置することは理にかなっています。これは、IdM ユーザーが管理されているのと全く同じ keystone ドメインである必要はありません。また、分離の目的で複数の keystone ドメインを使用することも可能です。

2.10.1. コマンドラインへの変更

特定のコマンドでは、対象のドメインを指定する必要がある場合があります。たとえば、以下のコマンドに --domain LAB を追加すると、LAB ドメイン内のユーザー (grp-openstack グループのメンバー) が返されます。

# openstack user list --domain LAB
Copy to Clipboard Toggle word wrap

--domain Default を追加すると、組み込みの keystone アカウントが返されます。

# openstack user list --domain Default
Copy to Clipboard Toggle word wrap

2.10.2. 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
Copy to Clipboard Toggle word wrap

idm.lab.local が利用できないためにクエリーが失敗した場合には、Identity サービスはリストに記載されている次のサーバー idm2.lab.local にクエリーの送信を試みます。この設定では、ラウンドロビン式にはクエリーが実行されないので、ロードバランスのソリューションとしては考慮できない点に注意してください。

2./etc/openldap/ldap.conf でネットワークのタイムアウトを設定します。

NETWORK_TIMEOUT 2
Copy to Clipboard Toggle word wrap

また、コントローラーと 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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap
注記

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
Copy to Clipboard Toggle word wrap

接続を確立できなかった場合には、ファイアウォールの設定に問題がある可能性があります。

第3章 一般的な LDAP 統合

本章では、Identity サービス(keystone)を一般的な LDAP 環境と統合する方法について説明します。

以下のユースケースでは、Identity サービスが特定の LDAP ユーザーを認証し、Identity サービスデータベースに承認設定および重要なサービスアカウントを保持します。その結果、Identity サービスは、ユーザーアカウント認証用に LDAP に読み取り専用でアクセスしますが、認証されたアカウントに割り当てる権限を引き続き管理するようになります。

3.1. 主要な用語

  • 認証: パスワードを使用して、ユーザーが本人であることを検証するプロセス。
  • 承認: 認証されたユーザーに対して、アクセスしようとしているシステムの適切なパーミッションが付与されていることを確認するプロセス。
  • ドメイン: Identity サービス内で設定する追加のバックエンド。たとえば、Identity サービスは、外部 LDAP 環境からユーザーを認証するように設定できます。このように設定されたユーザーの集合は、ドメイン として考えることができます。

3.2. 前提条件

本ガイドのデプロイメント例は、以下を前提としています。

  • LDAP サーバーが設定されており、稼働していること。
  • Red Hat OpenStack Platform が設定済みで、稼働していること。
  • DNS 名前解決が完全に機能しており、かつ全ホストが適切に登録されていること。
重要

Red Hat OpenStack Platform のこのバージョンでは、マルチドメインダッシュボード設定はサポートされません。本書では、1 つのドメインのダッシュボード設定についてのみ説明しています。

3.3. 影響評価

以下の手順は、LDAP ユーザーが OpenStack に対して認証を実行して、リソースにアクセスできるようにします。OpenStack のサービスアカウント(keystone、glance など)および承認管理(パーミッションおよびロール)は Identity サービスのデータベースに残ります。パーミッションおよびロールは、Identity サービスの管理ツールを使用して LDAP アカウントに割り当てられます。

3.3.1. 高可用性のオプション

この設定により、単一の LDAP サーバーの可用性の依存関係が作成されます。Identity サービスが LDAP サーバーに対して認証できない場合には、プロジェクトユーザーが影響を受けることになります。このリスクを管理するオプションは複数あります。たとえば、keystone が個別の LDAP サーバーではなく DNS エイリアスや負荷分散アプライアンスにクエリーを実行するように設定することが可能です。また、別の LDAP サーバーが利用できなくなった場合に、異なる LDAP サーバーにクエリーを実行するように keystone を設定することもできます。詳細は、「高可用性の設定」 を参照してください。

3.4. 停止の要件

  • LDAP バックエンドを追加するには、Identity サービスを再起動する必要があります。
  • keystone v3 に切り替えるには、全ノード上の Compute サービスを再起動する必要があります。
  • ユーザーは、LDAP でアカウントが作成されるまでは、Dashboard にアクセスできません。ダウンタイムを短縮するには、この変更の前に十分余裕をもって LDAP アカウントのプレステージを行うことを検討してください。

3.5. ファイアウォールの設定

ファイアウォールが LDAP と OpenStack の間のトラフィックをフィルタリングしている場合には、以下のポートを介したアクセスを許可する必要があります。

Expand
ソース送信先タイプポート

OpenStack コントローラーノード

LDAP サーバー

LDAPS

TCP 636

3.6. LDAP サーバーの設定

LDAP サーバーで次の手順を実行して、Identity サービスの統合を準備します。

1.LDAP ルックアップアカウントを作成します。

このアカウントは、Identity サービスが LDAP サービスにクエリーを実行するのに使用されます。標準のパスワードポリシー要件に加えて、このデプロイメントには次の属性が必要です。

  • First name: OpenStack
  • : LDAP
  • ユーザー名: svc-ldap
注記

作成が完了したら、このアカウントのパスワード期限の設定を確認してください。

2. grp-openstack という名前の OpenStack ユーザーの LDAP グループを作成します。OpenStack Identity でパーミッションを割り当てることができるのは、このグループのメンバーのみです。

3.svc-ldap アカウントのパスワードを設定して、grp-openstack グループに追加します。

3.7. LDAPS 証明書の設定

1.LDAP 環境で、LDAPS 証明書を見つけます。このファイルの場所は、/etc/openldap/ldap.conf で確認することができます。

TLS_CACERT /etc/ipa/ca.crt
Copy to Clipboard Toggle word wrap

2.OpenStack Identity (keystone)を実行中のノードにファイルをコピーします。たとえば、以下のコマンドは scp を使用して ca.crt を node.lab.local という名前のコントローラーノードにコピーします。

scp /etc/ipa/ca.crt root@node.lab.local:/root/
Copy to Clipboard Toggle word wrap

3.コントローラーノードで .crt を .pem に変換します。

# openssl x509 -in ca.crt -out ca.pem -outform PEM
Copy to Clipboard Toggle word wrap

4.OpenStack コントローラーに .pem をインストールします。たとえば、Red Hat Enterprise Linux の場合は以下を実行します。

# cp ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
Copy to Clipboard Toggle word wrap

5..crt を証明書のディレクトリーにコピーします。

# cp ca.crt /etc/ssl/certs/
Copy to Clipboard Toggle word wrap

3.8. Identity サービスの設定

以下のステップでは、LDAP と統合するための Identity サービスの準備を行います。

3.8.1. keystone v3 へのコマンドラインへのアクセスを有効にする

コマンドラインから Identity サービスドメインを管理するには、keystone v3 へのアクセスを有効にする必要があります。

keystone サービスを実行しているコントローラーから、この手順を実行します。

1.既存の環境変数ファイルのコピーを作成します。director ベースのデプロイメントでは、overcloudrc と呼ばれます。

$ cp overcloudrc overcloudrc-v3
Copy to Clipboard Toggle word wrap

2. 新しい overcloudrc-v3 ファイルを編集します。

  • OS_AUTH_URLv2.0 から v 3 に変更します。以下に例を示します。
export OS_AUTH_URL=https://controllerIP:5000/v3/
Copy to Clipboard Toggle word wrap
  • 以下のエントリーを overcloudrc-v3 の下部に追加します。
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
Copy to Clipboard Toggle word wrap

3.ファイルを調達して、現在のコマンドラインセッションで以下のオプションを有効にします。

$ source overcloudrc-v3
Copy to Clipboard Toggle word wrap

3.8.2. コントローラーの設定

keystone サービスを実行しているコントローラーから、以下の手順を実行します。

1.SELinux を設定します。

# setsebool -P authlogin_nsswitch_use_ldap=on
Copy to Clipboard Toggle word wrap

2.domains ディレクトリーを作成します。

# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/
Copy to Clipboard Toggle word wrap

3.Identity サービスが複数のバックエンドを使用するように設定します。

注記

yum install crudini のコマンドを実行して crudini をインストールする必要がある場合があります。

# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql
Copy to Clipboard Toggle word wrap
注記

Red Hat OpenStack Platform director を使用している場合は、/etc/keystone/keystone.conf が Puppet によって管理されていることを認識する必要があります。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。director の今後のリリースでは、デプロイ後のスクリプトを使用してこれらの設定を自動的に適用できるようにする Puppet パラメーターが含まれる予定です。

4.追加のバックエンドを設定します。

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

# openstack domain create LAB
Copy to Clipboard Toggle word wrap
注記

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

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

LDAP バックエンドを追加するには、/etc/keystone/domains/keystone.LAB.conf という名前の新規ファイルに LDAP 設定を入力します( LAB は、前のステップで作成したドメイン名に置き換えます)。以下の設定例は、お使いの 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
Copy to Clipboard Toggle word wrap

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

Expand
設定説明

url

認証に使用する LDAP サーバー。LDAPS ポート 636 を使用します。

user

LDAP クエリーに使用する LDAP のアカウント。

password

上記で使用した LDAP アカウントのパスワード(プレーンテキスト形式)。

user_filter

Identity サービスに対して提示するユーザーをフィルタリングします。その結果、grp-openstack グループのメンバーのみに Identity サービスで定義されているパーミッションを付与することができます。

user_tree_dn

LDAP 内の OpenStack アカウントへのパス。

user_objectclass

LDAP ユーザーの種別を定義します。LDAP には inetUser タイプを使用します。

user_id_attribute

ユーザー ID に使用する LDAP 値をマッピングします。

user_name_attribute

名前に使用する LDAP 値をマッピングし ます

user_mail_attribute

ユーザーのメールアドレスに使用する LDAP 値をマッピングします。

user_pass_attribute

この値は空白のままにします。

user_allow_create

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

user_allow_update

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

user_allow_delete

keystone では読み取り専用アクセスのみが必要であるため、この値を False に設定します。

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

# chown keystone /etc/keystone/domains/keystone.LAB.conf
Copy to Clipboard Toggle word wrap

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

注記

これにより、OpenStack admin アカウントには LDAP のパーミッションは付与されません。ここで使われるドメインという用語は、OpenStack が使用する keystone ドメインのことを指しています。

a.LAB ドメインの ID を取得します。

# openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+
Copy to Clipboard Toggle word wrap

b.admin ユーザーの ID の値を取得します。

# openstack user list --domain default | grep admin

| 3d75388d351846c6a880e53b2508172a | admin      |
Copy to Clipboard Toggle word wrap

c.admin ロールの ID の値を取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
Copy to Clipboard Toggle word wrap

d.返されたドメインおよび admin の ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。

# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
Copy to Clipboard Toggle word wrap

7. ログインページで LAB keystone ドメインを使用するように Dashboard を設定します。/etc/openstack-dashboard/local_settings に以下の行を追加します。

重要

Red Hat OpenStack Platform のこのバージョンでは、マルチドメインダッシュボード設定はサポートされません。本書では、1 つのドメインのダッシュボード設定についてのみ説明しています。

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
Copy to Clipboard Toggle word wrap
注記

Red Hat OpenStack Platform director を使用している場合は、/etc/openstack-dashboard/local_settings が Puppet によって管理されていることを認識する必要があります。このため、openstack overcloud deploy プロセスを実行するたびに、自分で追加したカスタム設定が上書きされる可能性があります。上書きされた場合には、この設定を毎回手動で追加し直す必要がある場合があります。director の今後のリリースでは、デプロイ後のスクリプトを使用してこれらの設定を自動的に適用できるようにする Puppet パラメーターが含まれる予定です。

8. httpd サービスを再起動して変更を適用します。

# systemctl restart httpd.service
Copy to Clipboard Toggle word wrap

9.コマンドで keystone ドメイン名を指定して、LDAP ドメイン内のユーザーのリストを表示します。

# openstack user list --domain LAB
Copy to Clipboard Toggle word wrap

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

# openstack user list --domain default
Copy to Clipboard Toggle word wrap

3.8.3. keystone v3 を使用するように Compute を設定する

Compute はデフォルトで keystone v2.0 を使用するので、マルチドメイン機能を使用するには keystone v3 を使用するように設定する必要があります。

1.各コンピュートノードで keystone_authtoken の値を調整します。

# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

3.各コンピュートノードでこのサービスを再起動して、変更を適用します。

# systemctl restart openstack-nova-compute.service
Copy to Clipboard Toggle word wrap

3.8.4. Block Storage が keystone v3 を使用するように設定する手順

keystone v3 に対して認証するには、Block Storage (cinder)も設定する必要があります。

  1. /etc/cinder/cinder.conf で以下を行います。

    [keystone_authtoken]
    auth_uri = https://controllerIP:5000/v3
    auth_version = v3
    Copy to Clipboard Toggle word wrap
    • auth_uri - controllerIP をコントローラーの IP アドレスに置き換えます。デプロイメントに複数のコントローラーがある場合には、コントローラー IP の代わりに keystone エンドポイントの仮想 IP を使用する必要があります。

3.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          |
+------------------------------------------------------------------+----------------+
Copy to Clipboard Toggle word wrap

2. ロールのリストを取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
Copy to Clipboard Toggle word wrap

3.リスト表示されたロールの中から 1 つまたは複数のロールをユーザーに追加して、プロジェクトへのアクセス権を付与します。たとえば、user1demo プロジェクトの一般ユーザーにするには、それらを _member_ ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
Copy to Clipboard Toggle word wrap

または、user1demo プロジェクトの管理ユーザーにするには、admin ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
Copy to Clipboard Toggle word wrap

その結果、user1 は LDAP ユーザー名とパスワードを入力して Dashboard にログインすることができます。

注記

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

3.9. ドメインタブへのアクセスの許可

admin ユーザーが Domain タブを見えるようにするには、そのユーザーを default ドメインで admin ロールに割り当てる必要があります。

  1. admin ユーザーの UUID を確認します。

    $ openstack user list | grep admin
    | a6a8adb6356f4a879f079485dad1321b | admin      |
    Copy to Clipboard Toggle word wrap
  2. default ドメインの admin ロールを admin ユーザーに追加します。

    $ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
    Copy to Clipboard Toggle word wrap

    その結果、admin ユーザーに Domain タブが見えるようになります。

3.10. 新規プロジェクトの作成

上記の統合ステップが完了した後に新規プロジェクトを作成する場合には、Default ドメインと、自分で作成した keystone ドメインのどちらに作成するかを決定する必要があります。これは、ワークフローとユーザーアカウントの管理方法を考慮して決定することができます。Default ドメインは、サービスアカウントと admin プロジェクトに使用する内部ドメインとして考えることができるので、AD でバッキングされているユーザーを異なる keystone ドメインに配置することは理にかなっています。これは、LDAP ユーザーが管理されているのと全く同じ keystone ドメインである必要はありません。また、分離の目的で複数の keystone ドメインを使用することも可能です。

3.10.1. コマンドラインへの変更

特定のコマンドでは、対象のドメインを指定する必要がある場合があります。たとえば、以下のコマンドに --domain LAB を追加すると、LAB ドメイン内のユーザー (grp-openstack グループのメンバー) が返されます。

# openstack user list --domain LAB
Copy to Clipboard Toggle word wrap

--domain Default を追加すると、組み込みの keystone アカウントが返されます。

# openstack user list --domain Default
Copy to Clipboard Toggle word wrap

3.10.2. LDAP インテグレーションのテスト

以下の手順では、ダッシュボードの機能へのユーザーアクセスをテストして、LDAP 統合を検証します。

1.LDAP にテストユーザーを作成し、そのユーザーを grp-openstack LDAP グループに追加します。

2. テストユーザーを demo テナントの _member_ ロールに追加します。

3.LDAP テストユーザーの認証情報を使用して Dashboard にログインします。

4.各タブをクリックし、エラーメッセージなしに正常に表示されているかどうかを確認します。

5.Dashboard を使用してテストインスタンスをビルドします。

注記

上記の手順で問題が発生した場合には、ステップ 3 から 5 までを組み込みの admin アカウントで実行してください。正常に実行されると、OpenStack が予想通りに機能していることが実証され、問題は LDAP .1-1.→ Identity 統合設定内のどこかにあることになります。「トラブルシューティング」を参照してください。

3.11. 高可用性の設定

keystone v3 が有効化されている場合には、ドメインの設定ファイルに複数の LDAP サーバーをリストすることで、この設定を高可用性にすることが可能です。

1.2 番目のサーバーを url エントリーに追加します。たとえば、keystone.LAB.conf ファイル内の url 設定を更新すると、Identity サービスはすべてのクエリートラフィックをリスト内で最初の LDAP サーバー( ldap.lab.local )に送信します。

url =  ldaps://ldap.lab.local,ldaps://ldap2.lab.local
Copy to Clipboard Toggle word wrap

ldap.lab.local が利用できないためにクエリーに失敗すると、Identity サービスはリスト内の次のサーバー ldap2.lab.local にクエリーの送信を試みます。この設定では、ラウンドロビン式にはクエリーが実行されないので、ロードバランスのソリューションとしては考慮できない点に注意してください。

2./etc/openldap/ldap.conf でネットワークのタイムアウトを設定します。

NETWORK_TIMEOUT 2
Copy to Clipboard Toggle word wrap

また、コントローラーと LDAP サーバーの間でファイアウォールを設定している場合は、LDAP サーバーがコントローラーからのパケットを通知せずに破棄するように設定しないでください。これにより、python-keystoneclient が機能停止を適切に検出して、リスト内の次の LDAP サーバーに要求をリダイレクトすることができます。

注記

クエリーがリストの第 2 の LDAP サーバーにリダイレクトされる間に接続の遅延が発生する可能性があります。これは、第 2 のサーバーへの接続を試みるには、第 1 のサーバーがタイムアウトになる必要があるためです。

3.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
Copy to Clipboard Toggle word wrap

3.13. トラブルシューティング

3.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
Copy to Clipboard Toggle word wrap
注記

ldapsearch は、openldap-clients パッケージに含まれています。このパッケージは、# yum install openldap-clients のコマンドを実行するとインストールすることができます。

3.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
Copy to Clipboard Toggle word wrap

接続を確立できなかった場合には、ファイアウォールの設定に問題がある可能性があります。

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat