17.2. OAuth 2.0 トークンベース認証の使用

1. Kafka クライアントは、クライアント ID およびクレデンシャル、および必要に応じてリフレッシュトークンを使用して、認可サーバーからアクセストークンを要求します。または、クライアントはユーザー名とパスワードを使用して認証することもできます。
2. 認可サーバーは新しいアクセストークンを生成します。
3. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して、有効期限の長いアクセストークンを渡すために Kafka ブローカーで認証します。
4. Kafka ブローカーは、独自のクライアント ID およびシークレットを使用し、認可サーバーでトークンイントロスペクションエンドポイントを呼び出すことで、アクセストークンを検証します。
5. トークンが有効な場合、Kafka クライアントセッションが確立されます。

1. Kafka クライアントは、クライアント ID およびクレデンシャル、および必要に応じてリフレッシュトークンを使用して、トークンエンドポイントから認可サーバーに対して認証を行います。または、クライアントはユーザー名とパスワードを使用して認証することもできます。
2. 認可サーバーは新しいアクセストークンを生成します。
3. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して、有効期限の長いアクセストークンを渡すために Kafka ブローカーで認証します。
4. Kafka ブローカーは、JWT トークン署名チェックおよびローカルトークンイントロスペクションを使用して、ローカルでアクセストークンを検証します。

1. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して、有効期限の長いアクセストークンを渡すために Kafka ブローカーで認証します。
2. Kafka ブローカーは、独自のクライアント ID およびシークレットを使用して、認可サーバーでトークンイントロスペクションエンドポイントを呼び出し、アクセストークンを検証します。
3. トークンが有効な場合、Kafka クライアントセッションが確立されます。

1. Kafka クライアントは、SASL OAUTHBEARER メカニズムを使用して、有効期限の長いアクセストークンを渡すために Kafka ブローカーで認証します。
2. Kafka ブローカーは、JWT トークン署名チェックおよびローカルトークンイントロスペクションを使用して、ローカルでアクセストークンを検証します。

1. Kafka クライアントは、clientId をユーザー名として、secret をパスワードとして渡します。
2. Kafka ブローカーは、トークンエンドポイントを使用して clientId および secret を認可サーバーに渡します。
3. 認可サーバーは、新しいアクセストークンまたはエラー (クライアントクレデンシャルが有効でない場合) を返します。

4. Kafka ブローカーは、以下のいずれかの方法でトークンを検証します。

   1. トークンイントロスペクションエンドポイントが指定されている場合、Kafka ブローカーは認可サーバーでエンドポイントを呼び出すことで、アクセストークンを検証します。トークンの検証に成功した場合には、セッションが確立されます。
   2. ローカルトークンのイントロスペクションが使用される場合、要求は認可サーバーに対して行われません。Kafka ブローカーは、JWT トークン署名チェックを使用して、アクセストークンをローカルで検証します。

1. Kafka クライアントはユーザー名とパスワードを渡します。パスワードは、クライアントを実行する前に手動で取得および設定されたアクセストークンの値を提供します。

2. Kafka ブローカーリスナーが認証のトークンエンドポイントで設定されているかどうかに応じて、$accessToken: 文字列の接頭辞の有無にかかわらず、パスワードは渡されます。

   1. トークンエンドポイントが設定されている場合、パスワードの前に $accessToken: を付け、password パラメーターにクライアントシークレットではなくアクセストークンが含まれていることをブローカーに知らせる必要があります。Kafka ブローカーは、ユーザー名をアカウントのユーザー名として解釈します。
   2. トークンエンドポイントが Kafka ブローカーリスナーで設定されていない場合 (no-client-credentials mode を強制)、パスワードは接頭辞なしでアクセストークンを提供する必要があります。Kafka ブローカーは、ユーザー名をアカウントのユーザー名として解釈します。このモードでは、クライアントはクライアント ID およびシークレットを使用せず、password パラメーターは常に raw アクセストークンとして解釈されます。

3. Kafka ブローカーは、以下のいずれかの方法でトークンを検証します。

   1. トークンイントロスペクションエンドポイントが指定されている場合、Kafka ブローカーは認可サーバーでエンドポイントを呼び出すことで、アクセストークンを検証します。トークンの検証に成功した場合には、セッションが確立されます。
   2. ローカルトークンイントロスペクションが使用されている場合には、認可サーバーへの要求はありません。Kafka ブローカーは、JWT トークン署名チェックを使用して、アクセストークンをローカルで検証します。

手順

1. Kafka リソースで、oauth 認証タイプのリスナーを指定します。

   OAuth 2.0 認証を使用したリスナー設定の例

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   spec:
     kafka:
       # ...
       listeners:
         - name: tls
           port: 9093
           type: internal
           tls: true
           authentication:
             type: oauth
         - name: external3
           port: 9094
           type: loadbalancer
           tls: true
           authentication:
             type: oauth
         #...

2. 認可サーバーおよび検証タイプに応じて OAuth リスナーを設定します。

   • 高速なローカル JWT トークン検証の設定
   • イントロスペクションエンドポイントを使用したトークン検証の設定
   • 追加の設定オプションの指定
3. Kafka 設定に変更を適用します。

4. 更新をログで確認するか、Pod 状態の遷移を監視して確認します。

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

   ローリング更新によって、ブローカーが OAuth 2.0 認証を使用するように設定されます。

手順

1. OAuth 2.0 サポートのあるクライアントライブラリーを Kafka クライアントの pom.xml ファイルに追加します。

   <dependency>
    <groupId>io.strimzi</groupId>
    <artifactId>kafka-oauth-client</artifactId>
    <version>0.15.1.redhat-00005</version>
   </dependency>

2. OAuth 2.0 認証方法に応じてクライアントを設定します。

   • クライアントシークレットを使用したクライアントクレデンシャルの設定例
   • パスワードグラントの設定例
   • アクセストークンの設定例
   • リフレッシュトークンの設定例

   たとえば、client.properties ファイルで認証方法のプロパティーを指定します。

3. OAUTH 2.0 認証のクライアントプロパティーを Java クライアントコードに入力します。

   クライアントプロパティーの入力を示す例

   Properties props = new Properties();
   try (FileReader reader = new FileReader("client.properties", StandardCharsets.UTF_8)) {
     props.load(reader);
   }

4. Kafka クライアントが Kafka ブローカーにアクセスできることを確認します。

手順

1. クライアントシークレットを作成し、これを環境変数としてコンポーネントにマウントします。

   以下は、Kafka Bridge の Secret を作成する例になります。

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Secret
   metadata:
    name: my-bridge-oauth
   type: Opaque
   data:
    clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 

   1

   1

   clientSecret キーは base64 形式である必要があります。

2. Kafka コンポーネントのリソースを作成または編集し、OAuth 2.0 認証が認証プロパティーに設定されるようにします。

   OAuth 2.0 認証の場合、次のオプションを使用できます。

   • クライアント ID およびシークレット
   • クライアント ID とクライアントアサーション
   • クライアント ID およびリフレッシュトークン
   • アクセストークン
   • ユーザー名およびパスワード
   • TLS

   以下は、クライアント ID、シークレット、および TLS を使用して OAuth 2.0 が Kafka Bridge クライアントに割り当てられる例になります。

   クライアントシークレットを使用した OAuth 2.0 認証設定の例

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth 

   1

   
       tokenEndpointUri: https://<auth_server_address>/<path_to_token_endpoint> 

   2

   
       clientId: kafka-bridge
       clientSecret:
         secretName: my-bridge-oauth
         key: clientSecret
       tlsTrustedCertificates: 

   3

   
         - secretName: oauth-server-cert
           pattern: "*.crt"

   1

   oauth に設定された認証タイプ。

   2

   認証用のトークンエンドポイントの URI。

   3

   認可サーバーへの TLS 接続用に指定されたシークレット内に X.509 形式で保存された証明書。

   この例では、クライアント ID とクライアントアサーションファイルの場所を使用して OAuth 2.0 が Kafka Bridge クライアントに割り当てられます。また、TLS を使用して認可サーバーに接続します。

   クライアントアサーションを使用した OAuth 2.0 認証設定の例

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth
       tokenEndpointUri: https://<auth_server_address>/<path_to_token_endpoint>
       clientId: kafka-bridge
       clientAssertionLocation: /var/run/secrets/sso/assertion 

   1

   
       tlsTrustedCertificates:
         - secretName: oauth-server-cert
           pattern: "*.crt"

   1

   クライアントの認証に使用されるクライアントアサーションファイルへのファイルシステムパス。このファイルは、通常、外部 Operator サービスによってデプロイされた Pod に追加されます。または、clientAssertion を使用して、クライアントアサーション値を含むシークレットを参照します。

   ここでは、サービスアカウントトークンを使用して、OAuth 2.0 が Kafka Bridge クライアントに割り当てられます。

   サービスアカウントトークンを使用した OAuth 2.0 認証設定の例

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth
       accessTokenLocation: /var/run/secrets/kubernetes.io/serviceaccount/token 

   1

   1

   サービスアカウントトークンファイルの場所へのパス。

   OAuth 2.0 認証の適用方法や、認可サーバーのタイプによって、使用できる追加の設定オプションがあります。

   その他の設定オプション

   # ...
   spec:
     # ...
     authentication:
       # ...
       disableTlsHostnameVerification: true 

   1

   
       accessTokenIsJwt: false 

   2

   
       scope: any 

   3

   
       audience: kafka 

   4

   
       connectTimeoutSeconds: 60 

   5

   
       readTimeoutSeconds: 60 

   6

   
       httpRetries: 2 

   7

   
       httpRetryPauseMs: 300 

   8

   
       includeAcceptHeader: false 

   9

   1

   (任意設定): TLS ホスト名の検証を無効にします。デフォルトは false です。

   2

   不透明なトークンを使用している場合、アクセストークンが JWT トークンとして処理されないように accessTokenIsJwt: false を適用することができます。

   3

   (オプション): トークンエンドポイントからトークンを要求するための scope。認可サーバーでは、クライアントによるスコープの指定が必要になることがあります。この場合では any になります。

   4

   (オプション) トークンエンドポイントからトークンを要求するための audience。認可サーバーでは、クライアントによるオーディエンスの指定が必要になることがあります。今回の場合は kafka です。

   5

   (オプション) 認可サーバーへの接続時のタイムアウト (秒単位)。デフォルト値は 60 です。

   6

   (オプション): 認可サーバーへの接続時の読み取りタイムアウト (秒単位)。デフォルト値は 60 です。

   7

   (オプション) 認可サーバーへの失敗した HTTP リクエストを再試行する最大回数。デフォルト値は 0 で、再試行は実行されないことを意味します。このオプションを効果的に使用するには、connectTimeoutSeconds オプションと readTimeoutSeconds オプションのタイムアウト時間を短縮することを検討してください。ただし、再試行により現在のワーカースレッドが他のリクエストで利用できなくなる可能性があり、リクエストが多すぎると停止する場合、Kafka ブローカーが応答しなくなる可能性があることに注意してください。

   8

   (オプション) 失敗した認可サーバーへの HTTP リクエストの再試行を行うまでの待機時間。デフォルトでは、この時間はゼロに設定されており、一時停止は適用されません。これは、リクエストの失敗の原因となる問題の多くは、リクエストごとのネットワークの不具合やプロキシーの問題であり、すぐに解決できるためです。ただし、認可サーバーに負荷がかかっている場合、または高トラフィックが発生している場合は、このオプションを 100 ミリ秒以上の値に設定して、サーバーの負荷を軽減し、再試行が成功する可能性を高めることができます。

   9

   (オプション) 一部の認可サーバーでは、クライアントが Accept: application/json ヘッダーを送信する際に問題が発生します。includeAcceptHeader: false を設定する場合、ヘッダーは送信されません。デフォルトは true です。

3. コンポーネントのリソース設定に変更を適用します。

4. 更新をログで確認するか、Pod 状態の遷移を監視して確認します。

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

   ローリング更新では、OAuth 2.0 認証を使用して Kafka ブローカーと対話するコンポーネントが設定されます。