検索

18.3. 認証プロバイダーについて

download PDF

認証プロバイダーは、ユーザーアイデンティティーのサードパーティーソース (アイデンティティープロバイダー (IDP) など) に接続し、ユーザーアイデンティティーを取得します。そして、そのアイデンティティーに基づいてトークンを発行し、そのトークンを Red Hat Advanced Cluster Security for Kubernetes (RHACS) に返します。このトークンにより、RHACS はユーザーを承認できるようになります。RHACS は、ユーザーインターフェイスおよび API 呼び出し内でトークンを使用します。

RHACS をインストールした後、ユーザーを認証するように IDP を設定する必要があります。

注記

IDP として OpenID Connect (OIDC) を使用している場合、RHACS は、ユーザー ID トークンまたは UserInfo エンドポイント応答から groupsemailuseridname などの特定のクレームの値を検査するマッピングルールに依存してユーザーを承認します。これらの詳細が存在しない場合、マッピングは成功せず、ユーザーは必要なリソースにアクセスできません。したがって、マッピングを成功させるには、IDP からのユーザーを承認するために必要なクレーム (groups など) が IDP の認証応答に含まれていることを確認する必要があります。

18.3.1. クレームマッピング

クレームは、アイデンティティプロバイダーが発行するトークン内にユーザーに関するデータを含めます。

クレームマッピングを使用すると、RHACS が IDP から受け取るクレーム属性を RHACS 発行トークンの別の属性にカスタマイズするかどうかを指定できます。クレームマッピングを使用しない場合、RHACS は RHACS 発行のトークンにクレーム属性を含めません。

たとえば、クレームマッピングを使用して、ユーザー ID の roles から RHACS 発行のトークンの groups にマッピングできます。

RHACS は、認証プロバイダーごとに異なるデフォルトのクレームマッピングを使用します。

18.3.1.1. OIDC のデフォルトのクレームマッピング

次のリストは、デフォルトの OIDC クレームマッピングを示しています。

  • sub から userid
  • name から name
  • email から email
  • groups から groups

18.3.1.2. Auth0 のデフォルトのクレームマッピング

Auth0 のデフォルトのクレームマッピングは、OIDC のデフォルトのクレームマッピングと同じです。

18.3.1.3. SAML 2.0 のデフォルトのクレームマッピング

次のリストは、SAML 2.0 のデフォルトのクレームマッピングに適用されます。

  • Subject.NameIDuserid にマッピングされる
  • 応答からのすべての SAML AttributeStatement.Attribute は、その名前にマッピングされる

18.3.1.4. Google IAP のデフォルトのクレームマッピング

次のリストは、Google IAP のデフォルトのクレームマッピングを示しています。

  • sub から userid
  • email から email
  • hd から hd
  • google.access_levels から access_levels

18.3.1.5. ユーザー証明書のデフォルトのクレームマッピング

ユーザー証明書は、サードパーティーの IDP と通信する代わりに、ユーザーが使用する証明書からユーザー情報を取得するため、他のすべての認証プロバイダーとは異なります。

ユーザー証明書のデフォルトのクレームマッピングには次のものが含まれます。

  • CertFingerprint から userid
  • Subject Common Name から name
  • EmailAddresses から email
  • Subject Organizational Unit から groups

18.3.1.6. OpenShift Auth のデフォルトのクレームマッピング

次のリストは、OpenShift Auth のデフォルトのクレームマッピングを示しています。

  • groups から groups
  • uid から userid
  • name から name

18.3.2. Rules

ユーザーを承認するために、RHACS は、ユーザー ID から groupsemailuseridname などの特定のクレームの値を検査するマッピングルールに依存します。ルールを使用すると、特定の値を持つ属性を持つユーザーを特定のロールにマッピングできます。例として、ルールには次の内容を含めることができます。key は emailvaluejohn@redhat.comroleAdmin です。

クレームが欠落している場合、マッピングは成功せず、ユーザーは必要なリソースにアクセスできません。したがって、マッピングを成功させるには、IDP からの認証応答に、ユーザー (groups など) を承認するために必要なクレームが含まれていることを確認する必要があります。

18.3.3. 最小アクセスロール

RHACS は、特定の認証プロバイダーが発行した RHACS トークンを使用して、すべての呼び出し元に最小限のアクセスロールを割り当てます。最小アクセスロールは、デフォルトでは None に設定されています。

たとえば、Analyst という最小アクセスロールを持つ認証プロバイダーがあるとします。その場合、このプロバイダーを使用してログインするすべてのユーザーには、Analyst ロールが割り当てられます。

18.3.4. 必須の属性

必須の属性は、ユーザー ID に特定の値の属性があるかどうかに基づいて、RHACS トークンの発行を制限できます。

たとえば、キー is_internal の属性の属性値が true である場合にのみトークンを発行するように RHACS を設定できます。is_internal 属性が false に設定されているか、設定されていないユーザーはトークンを取得しません。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.