委任トークンを使用した認証

委任トークンに基づく認証は、既存の SASL/SSL メソッドを補完するために使用できる軽量な認証メカニズムです。委任トークンは Apache Kafka® のブローカーとクライアント間で共有するシークレットです。委任トークンにより、フレームワークはセキュアな環境で利用可能なワーカーにワークロードを配分できます。このとき、Kerberos の TGT やキータブあるいは双方向の SSL を使用するときのキーストアを配分する追加コストは不要です。

委任トークンを使用するための一般的な手順を次に示します。

  • Kafka クラスターを SASL または SSL 経由で認証して、委任トークンを取得します。それには、AdminClient API または kafka-delegation-tokens スクリプトを使用します。
  • Kafka クラスターを認証するために、委任トークンを Kafka クライアントにセキュアに渡します。
  • トークンのオーナーまたは更新担当は、委任トークンを更新したり、失効させたりできます。

トークンの管理

委任トークンは、プライマリシークレットキーを使用して生成し検証します。シークレットキーは構成オプション delegation.token.master.key で指定します。すべてのブローカーで同じシークレットキーを構成する必要があります。シークレットが設定されていない、または空の文字列が設定されている場合、ブローカーにより委任トークン認証は無効にされます。

現在の実装では、トークンの詳細情報は ZooKeeper に格納され、ZooKeeper がプライベートネットワークにある Kafka インストールで利用できます。プライマリシークレットキーは server.properties 構成ファイルにプレーンテキストで格納されます。

トークンには、現在の有効期間と最大更新可能期間があります。デフォルトでは、トークンは最大 7 日間有効で、24 時間ごとに更新する必要があります。トークンの有効期間は、delegation.token.expiry.time.ms および delegation.token.max.lifetime.ms 構成オプションを使用して構成できます。

トークンを明示的にキャンセルすることもできます。トークンが有効期限までに更新されない場合、または最大有効期限を超過した場合、そのトークンはすべてのブローカーのキャッシュと ZooKeeper から削除されます。

委任トークンの作成

トークンは、AdminClient API または kafka-delegation-tokens スクリプトを使用して作成できます。委任トークンのリクエスト(作成、更新、失効、詳細表示)は、SASL または SSL で認証済みのチャンネルで発行する必要があります。初期認証が委任トークンを使用して実行された場合は、トークンをリクエストできません。kafka-delegation-tokens スクリプトの例を次に示します。

委任トークンを作成する場合

bin/kafka-delegation-tokens --bootstrap-server localhost:9092 --create --max-life-time-period -1 \
--command-config client.properties --renewer-principal User:user1

委任トークンを更新する場合

bin/kafka-delegation-tokens --bootstrap-server localhost:9092 --renew --renew-time-period -1 \
--command-config client.properties --hmac ABCDEFGHIJK

委任トークンを失効させる場合

bin/kafka-delegation-tokens --bootstrap-server localhost:9092 --expire --expiry-time-period -1 \
--command-config client.properties  --hmac ABCDEFGHIJK

既存のトークンの情報を --describe オプションで表示する場合

bin/kafka-delegation-tokens --bootstrap-server localhost:9092 --describe \
--command-config client.properties  --owner-principal User:user1

トークンの認証

委任トークンの認証は、現在の SASL/SCRAM 認証メカニズムをベースに動作します。SASL/SCRAM メカニズムは Kafka クラスターで有効にする必要があります(こちらの説明 を参照)。

Kafka クライアントの構成

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

sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
     username="tokenID123" \
     password="lAYYSFmLs4bTjf+lTZ1LCHR/ZZFNA==" \
     tokenauth="true";

オプション usernamepassword は、トークン ID とトークン HMAC を構成するために、クライアントで使用されます。そしてオプション tokenauth が、サーバーに対してトークン認証を示すために使用されます。この例では、各クライアントは、トークン ID tokenID123 を使用してブローカーに接続します。異なるトークンの詳細情報を sasl.jaas.config に指定することで、JVM内の異なるクライアントが、異なるトークンを使用して接続できます。

シークレットの手動ローテーションの手順

シークレットをローテーションした場合は、Kafka クラスターを再びデプロイする必要があります。この処理の間、現在接続されているクライアントは引き続き動作しますが、新しい接続リクエストと古いトークンの更新および失効リクエストは失敗することがあります。次に手順を示します。

  1. 既存のすべてのトークンを失効させます。
  2. ローリングアップグレードでシークレットをローテーションします。
  3. 新しいトークンを生成します。

委任トークンの注意事項

現時点で、作成できるのは自身の委任トークンだけです。トークンのオーナーまたは更新担当は、委任トークンを更新したり、失効させたりできます。また、自身のトークンの情報を表示することもできます。他のトークンの情報を表示するには、DESCRIBE アクセス許可を Token Resource に追加する必要があります。