4.10.6.2. Kafka ブローカーの OAuth 2.0 サポートの設定
この手順では、ブローカーリスナーが承認サーバーを使用して OAuth 2.0 認証を使用するように、Kafka ブローカーを設定する方法について説明します。
TLS リスナーを設定して、暗号化されたインターフェースで OAuth 2.0 を使用することが推奨されます。プレーンリスナーは推奨されません。
選択した承認サーバーおよび実装している承認のタイプをサポートするプロパティーを使用して、Kafka ブローカーを設定します。
作業を開始する前の注意事項
Kafka ブローカーリスナーの設定および認証に関する詳細は、以下を参照してください。
リスナー設定で使用されるプロパティーの説明は、以下を参照してください。
前提条件
- AMQ Streams および Kafka が稼働している必要があります。
- OAuth 2.0 の承認サーバーがデプロイされている必要があります。
手順
server.properties
ファイルで Kafka ブローカーリスナー設定を設定します。たとえば、OAUTHBEARER メカニズムを使用する場合:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow listener.name.client.oauthbearer.sasl.jaas.config
の一部としてブローカー接続設定を定義します。この例では、接続設定オプションを示しています。
例 1: JWKS エンドポイント設定を使用したローカルトークンの検証
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例 2: OAuth 2.0 イントロスペクションエンドポイントを使用した承認サーバーへのトークン検証の委譲
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ oauth.introspection.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/introspection" \ # ...
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ oauth.introspection.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/introspection" \ # ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な場合は、承認サーバーへのアクセスを設定します。
この手順は通常、サービスメッシュ などの技術がコンテナーの外部でセキュアなチャネルを設定するために使用される場合を除き、実稼働環境で必要になります。
セキュアな承認サーバーに接続するためのカスタムトラストストアを指定します。承認サーバーへのアクセスには、SSL が常に必要になります。
プロパティーを設定してトラストストアを設定します。
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書のホスト名がアクセス URL ホスト名と一致しない場合は、証明書のホスト名の検証をオフにすることができます。
oauth.ssl.endpoint.identification.algorithm=""
oauth.ssl.endpoint.identification.algorithm=""
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このチェックは、クライアントによる承認サーバーへの接続が信頼できることを確認します。実稼働以外の環境で検証をオフにすることもできます。
選択した認証フローに従って、追加のプロパティーを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 承認サーバーへの OAuth 2.0 トークンエンドポイント URL。本番環境では常に HTTPs を使用してください。
KeycloakRBACAuthorizer
を使用する場合、またはブローカー間の通信に OAuth 2.0 が有効なリスナーが使用されている場合に必要です。 - 2
- (任意設定) カスタムクレームチェック。検証時に追加のカスタムルールを JWT アクセストークンに適用する JsonPath フィルタークエリー。アクセストークンに必要なデータが含まれていないと拒否されます。イントロスペクション エンドポイントメソッドを使用する場合は、カスタムチェックがイントロスペクションエンドポイントの応答 JSON に適用されます。
- 3
- (任意設定): トークンエンドポイントに渡される
scope
パラメーター。スコープは、ブローカー間認証用にアクセストークンを取得する場合に使用されます。また、clientId
およびsecret
を使用した OAuth 2.0 over PLAIN クライアント認証のクライアントの名前でも使用されます。これは、承認サーバーに応じて、トークンの取得機能とトークンの内容のみに影響します。リスナーによるトークン検証ルールには影響しません。 - 4
- (任意設定) Audience のチェック。承認サーバーによって
aud
(オーディエンス) クレームが提供され、オーディエンスチェックを強制する場合は、ouath.check.audience
をtrue
に設定します。オーディエンスチェックによって、トークンの目的の受信者が特定されます。そのため、Kafka ブローカーによって、aud
クレームにclientId
のないトークンは拒否されます。デフォルトはfalse
です。 - 5
- (任意設定) トークンエンドポイントに渡される
audience
パラメーター。オーディエンスは、ブローカー間認証用にアクセストークンを取得する場合に使用されます。また、clientId
およびsecret
を使用した OAuth 2.0 over PLAIN クライアント認証のクライアントの名前でも使用されます。これは、承認サーバーに応じて、トークンの取得機能とトークンの内容のみに影響します。リスナーによるトークン検証ルールには影響しません。 - 6
- 有効な発行者の URI。この発行者が発行するアクセストークンのみが受け入れられます (常に必須です)。
- 7
- すべてのブローカーで同一の、Kafka ブローカーの設定されたクライアント ID。これは、
kafka-broker
として承認サーバーに登録されたクライアント です。イントロスペクションエンドポイントがトークンの検証に使用される場合、またはKeycloakRBACAuthorizer
が使用される場合に必要です。 - 8
- すべてのブローカーで同一の、Kafka ブローカーの設定されたシークレット。ブローカーが承認サーバーに対して認証する必要がある場合は、クライアントシークレット、アクセストークン、または更新トークンのいずれかを指定する必要があります。
- 9
- (任意設定) Kafka ブローカーの有効期間の長い更新トークン。
- 10
- (任意設定) Kafka ブローカーの有効期間の長いアクセストークン。
OAuth 2.0 認証の適用方法や、使用される承認サーバーのタイプに応じて、さらに設定を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 承認サーバーが
iss
クレームを提供しない場合は、発行者チェックを行うことができません。このような場合には、oauth.check.issuer
をfalse
に設定し、oauth.valid.issuer.uri
を指定しないようにします。デフォルトはtrue
です。 - 2
- 承認サーバーは、通常ユーザーとクライアントの両方を識別する単一の属性を提供しない場合があります。クライアントが独自の名前で認証される場合、サーバーによって クライアント ID が提供されることがあります。更新トークンまたはアクセストークンを取得するために、ユーザー名およびパスワードを使用してユーザーが認証される場合、サーバーによってクライアント ID の他に ユーザー名 が提供されることがあります。プライマリーユーザー ID 属性が使用できない場合は、このフォールバックオプションで、使用するユーザー名クレーム (属性) を指定します。
- 3
oauth.fallback.username.claim
が適用される場合、ユーザー名クレームの値とフォールバックユーザー名クレームの値が競合しないようにする必要もあることがあります。producer
というクライアントが存在し、producer
という通常ユーザーも存在する場合について考えてみましょう。この 2 つを区別するには、このプロパティーを使用してクライアントのユーザー ID に接頭辞を追加します。- 4
- (
oauth.introspection.endpoint.uri
を使用する場合のみ該当): 使用している認証サーバーによっては、イントロスペクションエンドポイントによってトークンタイプ属性が返されるかどうかは分からず、異なる値が含まれることがあります。イントロスペクションエンドポイントからの応答に含まれなければならない有効なトークンタイプ値を指定できます。 - 5
- (
oauth.introspection.endpoint.uri
を使用する場合のみ該当): イントロスペクションエンドポイントの応答に識別可能な情報が含まれないように、承認サーバーが設定または実装されることがあります。ユーザー ID を取得するには、userinfo
エンドポイントの URI をフォールバックとして設定します。oauth.fallback.username.claim
、oauth.fallback.username.claim
、およびoauth.fallback.username.prefix
設定がuserinfo
エンドポイントの応答に適用されます。
次のステップ