4.10.6.2. Kafka ブローカーの OAuth 2.0 サポートの設定

PDF

この手順では、ブローカーリスナーが承認サーバーを使用して OAuth 2.0 認証を使用するように、Kafka ブローカーを設定する方法について説明します。

TLS リスナーを設定して、暗号化されたインターフェースで OAuth 2.0 を使用することが推奨されます。プレーンリスナーは推奨されません。

選択した承認サーバーおよび実装している承認のタイプをサポートするプロパティーを使用して、Kafka ブローカーを設定します。

作業を開始する前の注意事項

Kafka ブローカーリスナーの設定および認証に関する詳細は、以下を参照してください。

リスナー設定で使用されるプロパティーの説明は、以下を参照してください。

OAuth 2.0 Kafka ブローカーの設定

前提条件

AMQ Streams および Kafka が稼働している必要があります。
OAuth 2.0 の承認サーバーがデプロイされている必要があります。

手順

server.properties ファイルで Kafka ブローカーリスナー設定を設定します。

たとえば、OAUTHBEARER メカニズムを使用する場合:

sasl.enabled.mechanisms=OAUTHBEARER
listeners=CLIENT://0.0.0.0:9092
listener.security.protocol.map=CLIENT:SASL_PLAINTEXT
listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
sasl.mechanism.inter.broker.protocol=OAUTHBEARER
inter.broker.listener.name=CLIENT
listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
listener.name.client.oauthbearer.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler

listener.name.client.oauthbearer.sasl.jaas.config の一部としてブローカー接続設定を定義します。

この例では、接続設定オプションを示しています。

例 1: JWKS エンドポイント設定を使用したローカルトークンの検証

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME" \
  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs" \
  oauth.jwks.refresh.seconds="300" \
  oauth.jwks.refresh.min.pause.seconds="1" \
  oauth.jwks.expiry.seconds="360" \
  oauth.username.claim="preferred_username" \
  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
  oauth.ssl.truststore.type="PKCS12" ;
listener.name.client.oauthbearer.connections.max.reauth.ms=3600000

例 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" \
  # ...

必要な場合は、承認サーバーへのアクセスを設定します。
この手順は通常、サービスメッシュ などの技術がコンテナーの外部でセキュアなチャネルを設定するために使用される場合を除き、実稼働環境で必要になります。
1. セキュアな承認サーバーに接続するためのカスタムトラストストアを指定します。承認サーバーへのアクセスには、SSL が常に必要になります。
  プロパティーを設定してトラストストアを設定します。
  以下に例を示します。
```
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  # ...
  oauth.client.id="kafka-broker" \
  oauth.client.secret="kafka-broker-secret" \
  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
  oauth.ssl.truststore.type="PKCS12" ;
```
2. 証明書のホスト名がアクセス URL ホスト名と一致しない場合は、証明書のホスト名の検証をオフにすることができます。
```
oauth.ssl.endpoint.identification.algorithm=""
```
  このチェックは、クライアントによる承認サーバーへの接続が信頼できることを確認します。実稼働以外の環境で検証をオフにすることもできます。
選択した認証フローに従って、追加のプロパティーを設定します。
```
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  # ...
  oauth.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token" \ 1
  oauth.custom.claim.check="@.custom == 'custom-value'" \ 2
  oauth.scope="SCOPE" \ 3
  oauth.check.audience="true" \ 4
  oauth.audience="AUDIENCE" \ 5
  oauth.valid.issuer.uri="https://https://AUTH-SERVER-ADDRESS/auth/REALM-NAME" \ 6
  oauth.client.id="kafka-broker" \ 7
  oauth.client.secret="kafka-broker-secret" \ 8
  oauth.refresh.token="REFRESH-TOKEN-FOR-KAFKA-BROKERS" \ 9
  oauth.access.token="ACCESS-TOKEN-FOR-KAFKA-BROKERS" ; 10
```
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 認証の適用方法や、使用される承認サーバーのタイプに応じて、さらに設定を追加します。
```
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  # ...
  oauth.check.issuer=false \ 1
  oauth.fallback.username.claim="CLIENT-ID" \ 2
  oauth.fallback.username.prefix="CLIENT-ACCOUNT" \ 3
  oauth.valid.token.type="bearer" \ 4
  oauth.userinfo.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/userinfo" ; 5
```
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 エンドポイントの応答に適用されます。

次のステップ

OAuth 2.0 を使用するように Kafka クライアントを設定します。

4.10.6.2. Kafka ブローカーの OAuth 2.0 サポートの設定

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links