1. Home
  2. Platform
  3. セキュリティ
  4. 認証
  5. SASL による認証

JAAS を使用した SASL による認証

Apache Kafka® のブローカーは SASL を使用したクライアント認証をサポートしています。SASL 認証は SSL 暗号化と同時に有効にできます（SSL クライアント認証は無効になります）。

ちなみに

これらの手順では、ZIP または TAR アーカイブを使用して Confluent Platform をインストールしているという想定に基づいています。詳細については「オンプレミスのデプロイ」を参照してください。

次の SASL メカニズムがサポートされます。

参考

この構成の動作例については、Confluent Platform デモ を参照してください。構成リファレンスについては、デモの docker-compose.yml ファイル を参照してください。

JAAS の構成

Kafka では Java Authentication and Authorization Service（ JAAS ）を SASL の構成に使用します。JAAS の構成をすべての SASL 認証メカニズムに対して指定する必要があります。JAAS に必要な情報を提供するように Kafka クライアントを構成する場合、方法は 2 つあります。

  • sasl.jaas.config 構成プロパティを使用して JAAS の構成を指定する（推奨）
  • 実行時に java.security.auth.login.config プロパティを使用して静的な JAAS の構成ファイルを JVM に渡す

その他の JAAS の構成

実行時に java.security.auth.login.config プロパティを使用して静的な JAAS の構成ファイルを JVM に渡すことで、ブローカーで JAAS を構成することもできます。以下に例を示します。

export KAFKA_OPTS="-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf"
bin/kafka-server-start etc/kafka/server.properties

JAAS 構成が異なるレベルで定義される場合、次の優先順位が使用されます。

  1. ブローカーの構成プロパティ listener.name.<listenerName>.<saslMechanism>.sasl.jaas.config
  2. 静的な JAAS の構成の <listenerName>.KafkaServer セクション
  3. 静的な JAAS 構成の KafkaServer セクション

KafkaServer は各ブローカーで使用される JAAS ファイルのセクション名です。このセクションでは、ブローカー間通信のためにブローカーで行われる SASL クライアント接続を含め、ブローカー用の SASL 構成オプションについて説明します。SASL を使用するように複数のリスナーを構成する場合、小文字のリスナー名の最後にピリオドを付けたものをプレフィックスとしてセクション名に追加します（sasl_ssl.KafkaServer など）。

クライアントの JAAS の構成

またクライアントでは、JAAS を構成する次の 2 つの方法があります。

  1. （推奨）構成プロパティ sasl.jaas.config に JAAS の構成自体を組み込みます。
  2. 実行時に java.security.auth.login.config プロパティを使用して静的な JAAS の構成ファイルを JVM に渡します。これはブローカーの場合と同じです。

JAAS の構成を sasl.jaas.config に組み込みます。以下に例を示します。

sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
   username="confluent" \
   password="confluent-secret";

クライアントプロパティ sasl.jaas.config と静的な JAAS の構成のシステムプロパティ java.security.auth.login.config の両方をクライアントで指定すると、クライアントプロパティ sasl.jaas.config が使用されます。

JAAS と Confluent Control Center

JVM 引数 -Djava.security.auth.login.config=/path/to/jaas.config で渡す代わりにクライアントプロパティ sasl.jaas.config を明示的に使用する必要があり、モニタリング対象の本稼働環境クラスターから分離された独自の Kafka クラスターがある Confluent Control Center を使用していて、セキュリティプロファイルが 2 つのクラスターで異なる、というシナリオについて考えます。

java.security.auth.login.config を使用する場合、モニタリング対象の本稼働環境クラスター、さらに Control Center を支援しているクラスターと JVM 全体で通信するために、単一の構成を設定することになります。これは、セキュリティプロファイルをクラスターごとに区別していないため、望ましくない状態です。

代わりに、クライアントプロパティを使用して、ターゲットクラスターに応じてセキュリティプロファイル（例: 異なる JAAS の構成）を区別します。

  • 本稼働環境のクラスター: sasl.jaas.config など
  • モニタリングクラスター: Confluent Metrics Reporter の場合 confluent.metrics.reporter.sasl.jaas.config を、Confluent Monitoring Interceptor の場合 confluent.monitoring.interceptor.sasl.jaas.config を使用

複数の SASL メカニズムの有効化

複数の SASL メカニズムをブローカーで同時に有効にできます。ただし各クライアントで 1 つのメカニズムを選択する必要があります。

JAAS の構成プロパティ（sasl.jaas.config）の使用

1 つのブローカーに複数の SASL メカニズムを指定する場合、ブローカー構成プロパティ sasl.jaas.config を使用する方法をお勧めします。プロパティ名の先頭にリスナーのプレフィックスを付け、SASL メカニズムを含める必要があります。以下に例を示します。

listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="admin" \
  password="admin-secret";
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
  username="admin" \
  password="admin-secret" \
  user_admin="admin-secret" \
  user_alice="alice-secret";

GSSAPI（Kerberos）および SCRAM SASL のメカニズムを sasl_plaintext リスナー向けに構成する場合の例は以下のとおりです。

sasl.enabled.mechanisms=SCRAM-SHA-512,GSSAPI
listener.name.sasl_plaintext.gssapi.sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
  useKeyTab=true \
  storeKey=true \
  keyTab="/var/lib/secret/kafka.key" \
  principal="kafka/kafka.kerberos-demo.local@TEST.CONFLUENT.IO";
listener.name.sasl_plaintext.scram-sha-512.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="kafka" \
  password="kafka";

JAAS の構成ファイルの使用

必要に応じて、1 つのブローカーに複数の SASL メカニズムを指定できます。その場合、ブローカーの JAAS の構成ファイルにある KafkaServer セクションで、有効なすべてのメカニズムのログインモジュールについて構成を指定します。以下に例を示します。

   KafkaServer {
   com.sun.security.auth.module.Krb5LoginModule required
   useKeyTab=true
   storeKey=true
   keyTab="/etc/security/keytabs/kafka_server.keytab"
   principal="kafka/kafka1.hostname.com@EXAMPLE.COM";

   org.apache.kafka.common.security.plain.PlainLoginModule required
   username="admin"
   password="admin-secret"
   user_admin="admin-secret"
   user_alice="alice-secret";
};

次のように、server.properties で SASL メカニズムを有効にします。

# List of enabled mechanisms, can be more than one
sasl.enabled.mechanisms=GSSAPI,PLAIN

必要に応じて、次のように、server.properties にブローカー間通信用の SASL のセキュリティプロトコルとメカニズムを指定します。

# Configure SASL_SSL if SSL encryption is enabled, otherwise configure SASL_PLAINTEXT
security.inter.broker.protocol=SASL_SSL

# Configure the appropriate inter-broker protocol
sasl.mechanism.inter.broker.protocol=GSSAPI

GSSAPI、 SCRAM、 PLAIN のメカニズム固有の手順に従って、有効にしたメカニズムに合わせて SASL を構成します。

動作しているクラスターでの SASL メカニズムの変更

動作しているクラスターの SASL メカニズムを変更するには

  1. 各ブローカーの server.properties の sasl.enabled.mechanisms に新しい SASL メカニズムを追加することで、そのメカニズムを有効にします。JAAS の構成ファイルをアップデートして、 ここ に示したとおり両方のメカニズムを含めます。エンドユーザーのダウンタイムを回避するための ローリング再起動 の推奨事項を考慮して、各クラスターノードを段階的に再起動します。
  2. 新しいメカニズムでクライアントを再起動します（必要な場合）。
  3. ブローカー間通信のメカニズムを変更するには（必要な場合）、sasl.mechanism.inter.broker.protocol の新しいメカニズムを server.properties に設定し、クラスターを段階的に再起動します。
  4. 古いメカニズムを削除するには（必要な場合）、server.properties の sasl.enabled.mechanisms から古いメカニズムを削除し、JAAS の構成ファイルから古いメカニズムのエントリを削除します。クラスターを段階的に再起動します。

上記の手順は、可能なすべてのメカニズムの変更に対応させるには、若干複雑である点に注意してください。たとえば、新しいメカニズムをブローカーに追加し、それを使用するようにクライアントを切り替えるには、手順 1 と 2 を実行する必要があります。