3.6. アイデンティティサービスとの連携

フェデレーション ID は、ID プロバイダーとサービスプロバイダー (SP) 間の信頼を確立するためのメカニズムです。この場合、サービスプロバイダーは OpenStack クラウドによって提供されるサービスです。

認証および承認サービスの場合、OpenStack アイデンティティーモデルは外部の認証データベースを別の keystone ドメインとみなします。各フェデレーション認証メカニズムは keystone ドメインに関連付けられ、複数の共存ドメインをサポートします。ロールを使用して、外部のドメインのユーザーにクラウドのリソースへのアクセスを許可できます。このアプローチは、ドメイン間のマルチテナントデプロイメントでも機能します。また、このアプローチは、すべての OpenStack ロールを外部認証ユーザーに戻すことができないため、コンポーネントごとのポリシーにも影響を与えます。たとえば、外部認証データベースのユーザーが admin ドメインの admin ユーザーと同様の管理アクセスが必要な場合は、通常は追加の設定や考慮が必要になります。

フェデレーション対応の Identity では、既存の認証情報を使用して、追加の ID を用意したり、複数回ログインしたりせずに、複数の認証クラウドで提供される複数のエンドポイント間で、サーバー、ボリューム、データベースなどのクラウドリソースにアクセスする方法を提供します。認証情報はユーザーの認証プロバイダーによって維持されます。

Identity サービスは、ユーザーの認証情報を SQL データベースに保存したり、LDAP 準拠のディレクトリーサーバーを使用したりできます。Identity データベースは、他の OpenStack サービスが使用するデータベースとは異なる可能性があり、保存された認証情報のリスクが軽減されます。

ユーザー名とパスワードを使用して認証する場合、Identity はパスワードの強度、有効期限、または失敗した認証試行でポリシーを強制しません。より強力なパスワードポリシーを強制する組織は、Identity 拡張機能または外部認証サービスを使用することを検討する必要があります。

LDAP は、Identity 認証を組織の既存のディレクトリーサービスおよびユーザーアカウントの管理プロセスに統合できるようにします。OpenStack の認証および承認ポリシーは、別のサービスに委譲される可能性があります。一般的なユースケースは、プライベートクラウドをデプロイするように組織で、LDAP システムに従業員およびユーザーのデータベースをすでに持つ組織です。これを認証機関として使用すると、Identity サービスへの要求は LDAP システムに委任され、そのポリシーに基づいて承認または拒否されます。認証に成功すると、Identity サービスは、承認されたサービスへのアクセスに使用されるトークンを生成します。

LDAP システムに admin、finance、HR など、ユーザーに属性が定義されている場合には、さまざまな OpenStack サービスで使用するために、Identity 内のロールおよびグループにマップされる必要があります。/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf ファイルは、LDAP 属性を Identity 属性にマッピングします。