3.7.5.2. Kafka ブローカーの OAuth 2.0 サポートの設定
この手順では、ブローカーリスナーが承認サーバーを使用して OAuth 2.0 認証を使用するように、Kafka ブローカーを設定する方法について説明します。
TLS リスナーを設定して、暗号化されたインターフェイスで OAuth 2.0 を使用することが推奨されます。プレーンリスナーは推奨されません。
承認サーバーが信頼できる CA によって署名された証明書を使用し、OAuth 2.0 サーバーのホスト名と一致する場合、TLS 接続はデフォルト設定を使用して動作します。その他の場合は、トークンの検証を承認サーバーに委譲するときに 2 つの設定オプションをリスナー設定に使用できます。
作業を開始する前の注意事項
Kafka ブローカーリスナーの OAuth 2.0 認証の設定に関する詳細は、以下を参照してください。
前提条件
- AMQ Streams および Kafka が稼働している。
- OAuth 2.0 の承認サーバーがデプロイされている。
手順
エディターで、
Kafkaリソースの Kafka ブローカー設定 (Kafka.spec.kafka) を更新します。oc edit kafka my-cluster
Kafka ブローカーの
listeners設定を行います。各タイプのリスナーは独立しているため、同じ設定にする必要はありません。
以下は、外部リスナーに設定された設定オプションの例になります。
例 1: 高速なローカル JWT トークン検証の設定
external: type: loadbalancer authentication: type: oauth 1 validIssuerUri: <https://<auth-server-address>/auth/realms/external> 2 jwksEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/certs> 3 userNameClaim: preferred_username 4 tlsTrustedCertificates: 5 - secretName: oauth-server-cert certificate: ca.crt disableTlsHostnameVerification: true 6 jwksExpirySeconds: 360 7 jwksRefreshSeconds: 300 8 enableECDSA: "true" 9- 1
oauthに設定されたリスナータイプ。- 2
- 認証に使用されるトークン発行者の URI。
- 3
- ローカルの JWT 検証に使用される JWKS 証明書エンドポイントの URI。
- 4
- トークンの実際のユーザー名が含まれるトークン要求 (またはキー)。ユーザー名は、ユーザーの識別に使用される principal です。
userNameClaimの値は、使用される認証フローと承認サーバーによって異なります。 - 5
- (任意設定): 承認サーバーへの TLS 接続用の信用できる証明書。
- 6
- (任意設定): TLS ホスト名の検証を無効にします。デフォルトは
falseです。 - 7
- JWK 証明書が期限切れになる前に有効とみなされる期間。デフォルトは
360秒です。デフォルトよりも長い時間を指定する場合は、取り消された証明書へのアクセスが許可されるリスクを考慮してください。 - 8
- JWK 証明書を更新する間隔。この間隔は、有効期間よりも 60 秒以上短くする必要があります。デフォルトは
300秒です。 - 9
- (任意設定): ECDSA を使用して承認サーバーで JWT トークンを署名する場合は、これを有効にする必要があります。BouncyCastle 暗号ライブラリーを使用して追加の暗号プロバイダーがインストールされます。デフォルトは
falseです。
例 2: イントロスペクションエンドポイントを使用したトークンの検証の設定
external: type: loadbalancer authentication: type: oauth validIssuerUri: <https://<auth-server-address>/auth/realms/external> introspectionEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token/introspect> 1 clientId: kafka-broker 2 clientSecret: 3 secretName: my-cluster-oauth key: clientSecret userNameClaim: preferred_username 4OAuth 2.0 認証の適用方法や、承認サーバーのタイプによっては、追加 (任意) の設定を使用できます。
# ... authentication: type: oauth # ... checkIssuer: false 1 fallbackUserNameClaim: client_id 2 fallbackUserNamePrefix: client-account- 3 validTokenType: bearer 4 userInfoEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/userinfo 5- 1
- 承認サーバーが
issクレームを提供しない場合は、発行者チェックを行うことができません。このような場合、checkIssuerをfalseに設定し、validIssuerUriを指定しないようにします。デフォルトはtrueです。 - 2
- 承認サーバーは、通常ユーザーとクライアントの両方を識別する単一の属性を提供しない場合があります。クライアントが独自の名前で認証される場合、サーバーによって クライアント ID が提供されることがあります。更新トークンまたはアクセストークンを取得するために、ユーザー名およびパスワードを使用してユーザーが認証される場合、サーバーによってクライアント ID の他に ユーザー名 が提供されることがあります。プライマリーユーザー ID 属性が使用できない場合は、このフォールバックオプションで、使用するユーザー名クレーム (属性) を指定します。
- 3
fallbackUserNameClaimが適用される場合、ユーザー名クレームの値とフォールバックユーザー名クレームの値が競合しないようにする必要もあることがあります。producerというクライアントが存在し、producerという通常ユーザーも存在する場合について考えてみましょう。この 2 つを区別するには、このプロパティーを使用してクライアントのユーザー ID に接頭辞を追加します。- 4
- (
introspectionEndpointUriを使用する場合のみ該当): 使用している認証サーバーによっては、イントロスペクションエンドポイントによってトークンタイプ属性が返されるかどうかは分からず、異なる値が含まれることがあります。イントロスペクションエンドポイントからの応答に含まれなければならない有効なトークンタイプ値を指定できます。 - 5
- (
introspectionEndpointUriを使用する場合のみ該当): イントロスペクションエンドポイントの応答に識別可能な情報が含まれないように、承認サーバーが設定または実装されることがあります。ユーザー ID を取得するには、userinfoエンドポイントの URI をフォールバックとして設定します。userNameClaim、fallbackUserNameClaim、およびfallbackUserNamePrefixの設定がuserinfoエンドポイントの応答に適用されます。
- エディターを保存して終了し、ローリング更新の完了を待ちます。
更新をログで確認するか、または Pod 状態の遷移を監視して確認します。
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get po -wローリング更新によって、ブローカーが OAuth 2.0 認証を使用するように設定されます。
