18.3. 認証プロバイダーについて
認証プロバイダーは、ユーザーアイデンティティーのサードパーティーソース (アイデンティティープロバイダー (IDP) など) に接続し、ユーザーアイデンティティーを取得します。そして、そのアイデンティティーに基づいてトークンを発行し、そのトークンを Red Hat Advanced Cluster Security for Kubernetes (RHACS) に返します。このトークンにより、RHACS はユーザーを承認できるようになります。RHACS は、ユーザーインターフェイスおよび API 呼び出し内でトークンを使用します。
RHACS をインストールした後、ユーザーを認証するように IDP を設定する必要があります。
IDP として OpenID Connect (OIDC) を使用している場合、RHACS は、ユーザー ID トークンまたは UserInfo
エンドポイント応答から groups
、email
、userid
、name
などの特定のクレームの値を検査するマッピングルールに依存してユーザーを承認します。これらの詳細が存在しない場合、マッピングは成功せず、ユーザーは必要なリソースにアクセスできません。したがって、マッピングを成功させるには、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.NameID
はuserid
にマッピングされる -
応答からのすべての 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 から groups
、email
、userid
、name
などの特定のクレームの値を検査するマッピングルールに依存します。ルールを使用すると、特定の値を持つ属性を持つユーザーを特定のロールにマッピングできます。例として、ルールには次の内容を含めることができます。key は email
、value
は john@redhat.com
、role
は Admin
です。
クレームが欠落している場合、マッピングは成功せず、ユーザーは必要なリソースにアクセスできません。したがって、マッピングを成功させるには、IDP からの認証応答に、ユーザー (groups
など) を承認するために必要なクレームが含まれていることを確認する必要があります。
18.3.3. 最小アクセスロール
RHACS は、特定の認証プロバイダーが発行した RHACS トークンを使用して、すべての呼び出し元に最小限のアクセスロールを割り当てます。最小アクセスロールは、デフォルトでは None
に設定されています。
たとえば、Analyst
という最小アクセスロールを持つ認証プロバイダーがあるとします。その場合、このプロバイダーを使用してログインするすべてのユーザーには、Analyst
ロールが割り当てられます。
18.3.4. 必須の属性
必須の属性は、ユーザー ID に特定の値の属性があるかどうかに基づいて、RHACS トークンの発行を制限できます。
たとえば、キー is_internal
の属性の属性値が true
である場合にのみトークンを発行するように RHACS を設定できます。is_internal
属性が false
に設定されているか、設定されていないユーザーはトークンを取得しません。