委任トークンを使用した認証¶
委任トークンに基づく認証は、既存の SASL/SSL メソッドを補完するために使用できる軽量な認証メカニズムです。委任トークンは Apache Kafka® のブローカーとクライアント間で共有するシークレットです。委任トークンにより、フレームワークはセキュアな環境で利用可能なワーカーにワークロードを配分できます。このとき、Kerberos の TGT やキータブあるいは双方向の TLS/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";
オプション username
と password
は、トークン ID とトークン HMAC を構成するために、クライアントで使用されます。そしてオプション tokenauth
が、サーバーに対してトークン認証を示すために使用されます。この例では、各クライアントは、トークン ID tokenID123
を使用してブローカーに接続します。異なるトークンの詳細情報を sasl.jaas.config
に指定することで、JVM内の異なるクライアントが、異なるトークンを使用して接続できます。
シークレットの手動ローテーションの手順¶
シークレットをローテーションした場合は、Kafka クラスターを再びデプロイする必要があります。この処理の間、現在接続されているクライアントは引き続き動作しますが、新しい接続リクエストと古いトークンの更新および失効リクエストは失敗することがあります。次に手順を示します。
- 既存のすべてのトークンを失効させます。
- ローリングアップグレードでシークレットをローテーションします。
- 新しいトークンを生成します。
委任トークンの注意事項¶
現時点で、作成できるのは自身の委任トークンだけです。トークンのオーナーまたは更新担当は、委任トークンを更新したり、失効させたりできます。また、自身のトークンの情報を表示することもできます。他のトークンの情報を表示するには、DESCRIBE
アクセス許可を Token Resource に追加する必要があります。