OAUTHBEARER の構成

OAuth 2 Authorization Framework を使用すると、サードパーティアプリケーションに HTTP サービスへの限定的なアクセス権限の取得を許可できます。リソースオーナーと HTTP サービスの間で承認のためのやり取りを調整することでリソースオーナーの代理としてサードパーティアプリケーションにアクセスを許可することも、サードパーティアプリケーション自身によるアクセス要求を許可することもできます。SASL OAUTHBEARER メカニズムでは、SASL(つまり HTTP 以外の)コンテキスト( RFC 7628 で定義)で、このフレームワークの使用が可能になります。Apache Kafka® での OAUTHBEARER のデフォルト実装では、セキュアではない JSON Web Tokens を作成し、検証します。これが適しているのは、本稼働環境以外の Kafka インストールだけです。詳細については、「SASL/OAUTHBEARER のセキュリティの考慮事項」を参照してください。

重要

外部クライアント通信には、トークンサービスまたは OAUTHBEARER の SASL メカニズム(listener.name.rbac.sasl.enabled.mechanisms=OAUTHBEARER)を使用しないでください。RBAC が有効になっている場合、トークンサービスの対象は Confluent Platform コンポーネント間の内部通信のみとなり(たとえば、Schema Registry ライセンスクライアントには有効)、長時間実行されるサービスプリンシパルやクライアント認証は対象になりません。OAUTHBEARER 設定は内部用であり、変更される可能性があります。また、フル機能の OAuth プロトコルは実装されていません。このため、長期またはクライアントのユースケースには、SASL や mTLS(相互 TLS)など、サポートされているいずれかの認証方法を使用してください。詳細については、「認証方法の概要」を参照してください。

Kafka ブローカーの構成

注釈

個別の JAAS ファイルの使用がサポートされていますが、このアプローチは "推奨されていません"。以下の手順 1 と 2 の代わりに、「Kafka ブローカーの推奨構成」で指定されているリスナーの構成を使用します。手順 3 はまだ必要であることに注意してください。

  1. 次に示すファイルと同様の、適切に変更された JAAS ファイルを各 Kafka ブローカーの構成ディレクトリに追加します。この例では、kafka_server_jaas.conf という名前です。

    KafkaServer {
        org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
        unsecuredLoginStringClaim_sub="admin";
    };
    

    KafkaServer セクションのプロパティ unsecuredLoginStringClaim_sub は、他のブローカーへの接続が開始されたときに、ブローカーで使用されます。この例では、admin はサブジェクト(sub )クレームに表示されます。これはブローカー間通信を行うユーザーです。

  2. JAAS の構成ファイルの場所を JVM パラメーターとして各 Kafka ブローカーに渡します。

    -Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf
    
  3. server.properties で SASL ポートと SASL メカニズムを構成します(ここ を参照)。

    以下に例を示します。

    listeners=SASL_SSL://host.name:port (or SASL_PLAINTEXT if non-production)
    security.inter.broker.protocol=SASL_SSL (or SASL_PLAINTEXT if non-production)
    sasl.mechanism.inter.broker.protocol=OAUTHBEARER
    sasl.enabled.mechanisms=OAUTHBEARER
    

カスタムコールバックハンドラーを使用している場合の OAuthBearerLoginModule ログインのオプション

同一 Java プロセス内のすべてのクライアント接続は、構成が異なっていない限り、同じログインを共有します。カスタムコールバックハンドラー(sasl.login.callback.handler.class)とともに OAuthBearerLoginModule を使用している場合、ログインのオプションはありません。したがって、すべてのクライアントが同じ認証トークンを共有します。これは、同じ JVM 内に異なるログインにより作成された複数の Kafka クライアントがある場合(たとえば、複数の Kafka コネクターを使用している場合)に問題となることがあります。

このような状況で同じ認証トークンをクライアントが共有しないようにするには、sasl.jaas.config を使用してログインが異なるように構成します(JVM のシステムプロパティ java.security.auth.login.config は使用しないでください)。つまり、ログインを分ける必要がある各クライアントの sasl.jaas.config に異なる値を指定する必要があります。これにより、ログインコールバックハンドラーが、それぞれの構成に従い正しいトークンを返すことが保証されます。

たとえば、次のログイン構成では、異なるログインのオプションを指定することで、各コネクターの SASL 構成を明示的にオーバーライドします。

"producer.override.sasl.jaas.config":"org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required kid=\"ABCDefgh11Pi7jKLMNOpq-R0s3TuVWxyzAbcDEFgHI0\"  login.id=\"kafka_producer_prem\" ;"

Kafka クライアントの構成

クライアントで SASL 認証を構成するには、以下のとおり実行します。

  1. 各クライアントの JAAS の構成プロパティを、producer.properties または consumer.properties で構成します。ログインモジュールで、プロデューサーやコンシューマーなどのクライアントが Kafka ブローカーに接続するための方法を記述します。OAUTHBEARER メカニズムを利用するクライアントの構成例を次に示します。

    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
         unsecuredLoginStringClaim_sub="alice";
    

    オプション unsecuredLoginStringClaim_sub は、サブジェクト(sub)クレーム(クライアント接続のユーザーを決定)を構成するために、クライアントで使用されます。この例では、クライアントはブローカーにユーザー alice として接続します。異なるサブジェクト(sub)クレームを sasl.jaas.config に指定することで、JVM 内の異なるクライアントは、異なるユーザーとして接続できます。

    ブローカーと同様に、クライアントに対する JAAS の構成を JVM パラメーターとして指定することもできます(ここ を参照)。各クライアントは KafkaClient というログインセクションを使用します。このオプションで許可されるのは、JVM からのすべてのクライアント接続に対して 1 ユーザーだけです。

  2. 次のプロパティを producer.properties または consumer.properties に構成します。

    security.protocol=SASL_SSL (or SASL_PLAINTEXT if non-production)
    sasl.mechanism=OAUTHBEARER
    
  3. SASL/OAUTHBEARER のデフォルト実装は、jackson-databind ライブラリをベースにしています。オプションの依存関係があるので、使用するビルドツールで依存関係も構成する必要があります。

SASL/OAUTHBEARER 向けのセキュアではないクライアント側トークンの作成オプション

  • Kafka での SASL/OAUTHBEARER のデフォルト実装では、セキュアではない JSON Web Tokens を作成し、検証します。本稼働環境以外での使用にのみ適していますが、開発またはテスト環境で任意のトークンを柔軟に作成できます。

  • クライアント側でサポートされている、さまざまな JAAS モジュールのオプションを次に示します(OAUTHBEARER がブローカー間プロトコルである場合はブローカー側でもサポートされます)。

    クライアント側 JAAS モジュールのオプション 説明
    unsecuredLoginStringClaim_<claimname>="value" 指定した名前と値で String クレームを作成します。iat および exp (自動生成)を除き、有効なクレーム名を指定できます。
    unsecuredLoginNumberClaim_<claimname>="value" 指定した名前と値で、Number クレームを作成します。iat および exp (自動生成)を除き、有効なクレーム名を指定できます。
    unsecuredLoginListClaim_<claimname>="value" 指定した名前と値で、String List クレームを作成します。値に指定した最初の文字が区切り文字と解釈されます。たとえば、unsecuredLoginListClaim_fubar="value1 value2" です。iat および exp (自動生成)を除き、有効なクレーム名を指定できます。
    unsecuredLoginPrincipalClaimName プリンシパル名を保持する String クレームの名前を「sub」以外にする場合に、カスタムのクレーム名に設定します。
    unsecuredLoginLifetimeSeconds デフォルト値 3600 秒(1 時間)以外にトークンの有効期限を設定する場合に、整数値を設定します。exp クレームに有効期限が反映されるように設定されます。
    unsecuredLoginScopeClaimName トークンスコープを保持する String または String List クレームの名前を「scope」以外にする場合に、カスタムのクレーム名を設定します。

SASL/OAUTHBEARER 向けのセキュアではないブローカー側トークンの検証オプション

  • ブローカー側で、セキュアではない JSON Web Token の検証に対してサポートされている、さまざまな JAAS モジュールのオプションを示します。

    ブローカー側 JAAS モジュールのオプション 説明
    unsecuredValidatorPrincipalClaimName="value" プリンシパル名を保持する特定の String クレームが存在することをチェックする必要がある場合に空ではない値を設定します。デフォルトでは 'sub' クレームの存在をチェックします。
    unsecuredValidatorScopeClaimName="value" トークンスコープを保持する String または String List クレームの名前を「scope」以外にする場合に、カスタムのクレーム名を設定します。
    unsecuredValidatorRequiredScope="value" トークンスコープを保持する String/String List クレームに、特定の値が含まれることをチェックする必要がある場合に、スコープ値のスペース区切りのリストを設定します。
    unsecuredValidatorAllowableClockSkewMs="value" クロックスキューを許容する正のミリ秒値(デフォルトは 0)が必要な場合、正の整数値を設定します。
  • セキュアではない SASL/OAUTHBEARER のデフォルト実装を、カスタムのログインおよび SASL サーバーコールバックハンドラーを使用して、オーバーライドできます。

  • セキュリティの考慮事項の詳細については、RFC 6749 Section 10 を参照してください。

SASL/OAUTHBEARER 用のトークン更新

Kafka では、クライアントがブローカーに引き続き接続できるように、期限切れの前にトークンを定期的に更新します。更新アルゴリズムの処理方法に影響するパラメーターは、プロデューサー、コンシューマー、ブローカーの構成の一部として指定されます。以下を参照してください。他のプロパティの詳細については、ドキュメントを参照してください。デフォルト値は一般に合理的なもので、つまりこれらの構成パラメーターを明示的に設定する必要はありません。

プロデューサー、コンシューマー、ブローカーの構成のプロパティ
sasl.login.refresh.window.factor
sasl.login.refresh.window.jitter
sasl.login.refresh.min.period.seconds
sasl.login.refresh.min.buffer.seconds

SASL/OAUTHBEARER の本稼働環境での使用

本稼働環境で使用するには、OAUTHBEARER トークンを作成し取得するログインコールバックハンドラーおよび OAUTHBEARER トークンをセキュアに検証するサーバーコールバックハンドラーをコーディングし実装する必要があります。

トークン取得用のログインコールバックハンドラー

org.apache.kafka.common.security.auth.AuthenticateCallbackHandlerorg.apache.kafka.common.security.oauthbearer.OAuthBearerTokenCallback のインスタンスを処理)の実装を用意する必要があります。ブローカー以外のクライアント用の sasl.login.callback.handler.class 構成オプション、またはブローカー用のプレフィックス付きの listener.name.sasl_ssl.oauthbearer.sasl.login.callback.handler.class 構成オプション(SASL/OAUTHBEARER がブローカー間プロトコルであるとき)を使用して、宣言できます。

トークン検証用のサーバーコールバックハンドラー

org.apache.kafka.common.security.auth.AuthenticateCallbackHandlerorg.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallback のインスタンスを処理)の実装を用意する必要があります。プレフィックス付きの listener.name.sasl_ssl.oauthbearer.sasl.server.callback.handler.class ブローカー構成オプションを使用して宣言できます。

SASL/OAUTHBEARER のセキュリティの考慮事項

  • Kafka での SASL/OAUTHBEARER のデフォルト実装では、セキュアではない JSON Web Tokens を作成し、検証します。適しているのは、本稼働環境以外で使用する場合のみです。
  • OAUTHBEARER を本稼働環境で使用できるのは、TLS 暗号化を使用して、トークンの傍受を防ぐ場合だけです。
  • セキュアではない SASL/OAUTHBEARER のデフォルト実装は、前に示した、カスタムのログインおよび SASL サーバーコールバックハンドラーでオーバーライドできます(本稼働環境では必須)。
  • 一般的な OAuth 2 のセキュリティの考慮事項については、RFC 6749 Section 10 を参照してください。