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

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

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

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

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

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

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

前提条件

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

手順

  1. 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

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

  3. 必要な場合は、承認サーバーへのアクセスを設定します。

    この手順は、通常、サービスメッシュ などの技術を使用してコンテナー外でセキュアなチャネルを設定する場合を除き、実稼働環境に必要です。

    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=""

      このチェックは、クライアントによる承認サーバーへの接続が認証されるようにします。非実稼働環境で検証をオフにする場合があります。

  4. 選択した認証フローに応じて追加のプロパティーを設定します。 

    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.check.audience="true" 3
  oauth.valid.issuer.uri="https://https://AUTH-SERVER-ADDRESS/auth/REALM-NAME" \ 4
  oauth.client.id="kafka-broker" \ 5
  oauth.client.secret="kafka-broker-secret" \ 6
  oauth.refresh.token="REFRESH-TOKEN-FOR-KAFKA-BROKERS" \ 7
  oauth.access.token="ACCESS-TOKEN-FOR-KAFKA-BROKERS" ; 8
    1
    承認サーバーへの OAuth 2.0 トークンエンドポイント URL。本番環境では常に HTTP を使用してください。KeycloakRBACAuthorizer を使用する場合や、ブローカー間の通信に OAuth 2.0 対応のリスナーが使用される場合に必要です。
    2
    （オプション） カスタム要求チェック。検証中に追加のカスタムルールを JWT アクセストークンに適用する JsonPath フィルタークエリー。アクセストークンに必要なデータが含まれていないと拒否されます。イントロスペクションエンドポイントメソッドを使用する場合 、 カスタムチェックはイントロスペクションエンドポイントの応答 JSON に適用されます。
    3
    （オプション） オーディエンスチェック。承認サーバーによって aud （オーディエンス）クレームが提供され、オーディエンスチェックを強制する場合は、ouath.check.audience を true に設定します。オーディエンスチェックによって、トークンの目的の受信者が特定されます。その結果、Kafka ブローカーは aud クレームに clientId のないトークンを拒否します。デフォルトは false です。
    4
    有効な発行者 URI。この発行者が発行するアクセストークンのみが許可されます。（常に必須です。）
    5
    すべてのブローカーで同じ Kafka ブローカーの設定済みのクライアント ID。これは、 kafka-brokerとして承認サーバーに登録されているクライアント です。イントロスペクションエンドポイントがトークンの検証に使用される場合、または KeycloakRBACAuthorizer が使用される場合に必要です。
    6
    すべてのブローカーで同じ Kafka ブローカーに設定されたシークレット。ブローカーが承認サーバーに対して認証する必要がある場合、クライアントシークレット、アクセストークン、または更新トークンを指定する必要があります。
    7
    （任意設定）: Kafka ブローカーの有効期限の長い更新トークン。
    8
    （任意設定）: Kafka ブローカーの有効期限の長いアクセストークン。

  5. 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 エンドポイントの応答に適用されます。

次のステップ