4.4.6.4. Kafka コンポーネントの OAuth 2.0 の設定

手順

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 および更新トークン
   • アクセストークン
   • TLS

   KafkaClientAuthenticationOAuth スキーマ参照は、それぞれの例を提供します。

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

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth 1
       tokenEndpointUri: https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token 2
       clientId: kafka-bridge
       clientSecret:
         secretName: my-bridge-oauth
         key: clientSecret
       tlsTrustedCertificates: 3
       - secretName: oauth-server-cert
         certificate: tls.crt

   1

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

   2

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

   3

   承認サーバーへの TLS 接続用の信用できる証明書。

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

   # ...
   spec:
     # ...
     authentication:
       # ...
       disableTlsHostnameVerification: true 1
       checkAccessTokenType: false 2
       accessTokenIsJwt: false 3
       scope: any 4
       audience: kafka 5

   1

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

   2

   承認サーバーによって、JWT トークン内部で typ (タイプ) 要求が返されない場合は、checkAccessTokenType: false を適用するとトークンタイプがチェックされず次に進むことができます。デフォルトは true です。

   3

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

   4

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

   5

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

3. Kafka リソースのデプロイメントに変更を適用します。

   oc apply -f your-file

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

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

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