Kafka の SASL 認証を使い分ける: PLAIN / SCRAM / GSSAPI / OAUTHBEARER 実務と CCAAK 対策

Kafka の認証は SASL を基盤に複数メカニズムを選べます。実務ではネットワーク境界や既存 IdP/Kerberos との整合、運用負荷、パフォーマンスを総合して決めます。試験（Confluent 認定: Apache Kafka 管理者/CCAAK）では、メカニズムの性質、listener 設計、inter-broker 設定の整合性を問われがちです。

本稿は公式ドキュメントの安定仕様に沿って、PLAIN / SCRAM / GSSAPI / OAUTHBEARER の正しい前提・設定・比較・トラブル事例を、試験対策と実務の両面で解説します。

SASL と Kafka の前提整理

Kafka はネットワーク経路の暗号化（SSL/TLS）と認証（SASL）を組み合わせます。security.protocol は PLAINTEXT/SSL/SASL_PLAINTEXT/SASL_SSL を取り、listener ごとに割り当てます。試験では、PLAIN を平文で流す構成（SASL_PLAINTEXT かつ TLS なし）の危険性を指摘できるかが基本です。

ブローカー間通信は inter-broker listener とメカニズムを別途指定します。sasl.mechanism.inter.broker.protocol はブローカーがクライアントとして他ブローカーへ接続する際の認証メカニズムで、listeners と inter.broker.listener.name の整合が必要です。複数メカニズムを有効化する場合は sasl.enabled.mechanisms に列挙し、必要に応じて listener.name.<listener>.sasl.enabled.mechanisms で制限します。

• PLAIN は簡易だが平文パスワードを扱うため TLS 同時使用が前提
• SCRAM はハッシュ化ストア＋チャレンジレスポンスでパスワード露出を避ける
• GSSAPI は Kerberos 依存。組織に KDC がある場合の第一候補
• OAUTHBEARER は外部 IdP と統合。ブローカー側のトークン検証実装が要点
• inter-broker は 1 メカニズムを明示選択（運用では SCRAM か GSSAPI が定番）

PLAIN と SCRAM: 最短経路と現実解

PLAIN は最も設定が簡単ですが、資格情報が平文で送られるため TLS 必須です。試験では、PLAIN 単独（SASL_PLAINTEXT）の選択肢は基本的に不正解と考えてよいです。

SCRAM（SCRAM-SHA-256/512）は、ブローカーに安全に保存されたハッシュを使うため、パスワード漏えいリスクを抑えつつ取り回しが良いのが強みです。ユーザー資格情報は kafka-configs.sh でユーザーエンティティに付与します（ZooKeeper 環境では ZK に、KRaft 環境ではメタデータクォーラムに安全に保存されます）。

• 実務では EXTERNAL=SCRAM+TLS、INTERNAL=SCRAM（TLS 省略も可だが推奨は TLS）という設計が多い
• inter-broker は SCRAM を選ぶとシンプル。専用ユーザーを作成して接続
• PLAIN は PoC や閉域・短期用途に限定し、原則 SCRAM へ移行

代表的な設定スニペット（ブローカー/クライアント）

# server.properties（ブローカー）
listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093
listener.security.protocol.map=INTERNAL:SASL_PLAINTEXT,EXTERNAL:SASL_SSL
inter.broker.listener.name=INTERNAL
sasl.enabled.mechanisms=PLAIN,SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
# 必要に応じてリスナー単位で許可メカニズムを制限
listener.name.external.sasl.enabled.mechanisms=SCRAM-SHA-512

# （ブローカーの JAAS は別ファイルで指定: -Djava.security.auth.login.config=...）
# KafkaServer セクション例（SCRAM で inter-broker 用ユーザーを使用）
# KafkaServer {
#   org.apache.kafka.common.security.scram.ScramLoginModule required
#   username="broker" password="broker-secret";
# };

# ユーザー資格情報の登録例（実行ホストで）
# kafka-configs.sh --alter --entity-type users --entity-name alice \
#   --add-config 'SCRAM-SHA-512=[password=alice-secret]'
# kafka-configs.sh --alter --entity-type users --entity-name broker \
#   --add-config 'SCRAM-SHA-512=[password=broker-secret]'

# client.properties（SCRAM クライアント）
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="alice" password="alice-secret";

# client.properties（PLAIN クライアント：テスト用途）
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
  username="alice" password="alice-secret";

GSSAPI/Kerberos: エンタープライズ統合の王道

Kerberos（GSSAPI）は、既存の企業 KDC と統合できるなら第一候補です。鍵配布（チケット）による相互認証が可能で、パスワード平文管理を避けられます。Kafka では各ブローカーとクライアントに対し principal と keytab を配布し、sasl.kerberos.service.name を共通化します（一般に kafka）。

JAAS では Krb5LoginModule を使用し、ブローカー側 KafkaServer セクションで useKeyTab=true, storeKey=true を設定します。principal の短縮（principal.to.local ルール）の不整合、時刻ずれ、DNS 逆引き失敗は典型的な障害要因です。

• DNS と時刻同期（NTP）は必須。時計ずれは GSSAPI エラーの主因
• principal は FQDN とレルムに一致（例: kafka/[email protected]）
• クライアント側は ticket cache も可（kinit）。ブローカーは keytab 運用が安定

OAUTHBEARER: 外部 IdP/JWT との連携

OAUTHBEARER は OAuth 2.0/OIDC によるトークンベース認証を Kafka に持ち込みます。クライアントはトークン発行エンドポイントからアクセストークンを取得し、SASL 初期応答で提示します。ブローカーはそのトークンを検証するサーバーコールバック（実装クラス）で署名・有効期限・スコープ等を検証します。

Kafka 本体はトークン検証の実装をプラガブルに提供する前提で、IdP との接続先や鍵の扱い（JWKS/Issuer 検証など）は運用側の実装次第です。試験では TLS 併用の必須性、リスナー単位でのメカニズム分離、inter-broker には OAUTHBEARER を使わない設計が安全という点が問われます。

• クライアント: sasl.login.callback.handler.class と sasl.oauthbearer.token.endpoint.url を設定
• ブローカー: listener.name.<listener>.oauthbearer.sasl.server.callback.handler.class を指定し検証を実装
• トークンは機密情報。TLS なしの OAUTHBEARER は避ける

クライアント最小設定例（OAUTHBEARER）

# client.properties（OAUTHBEARER）
security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler
sasl.oauthbearer.token.endpoint.url=https://idp.example.com/oauth2/token
# 必要に応じて clientId/clientSecret, scope など（LoginCallbackHandler 実装依存）

リスナー設計とメカニズムの混在: 型を決めて安全に運用

外部と内部で listener を分け、外部は TLS 前提の強固なメカニズム（SCRAM もしくは OAUTHBEARER）、内部や inter-broker は運用負荷の低い SCRAM/GSSAPI を選ぶのが実務定石です。listener.name.<listener>.sasl.enabled.mechanisms で露出するメカニズムを限定し、誤用を防ぎます。

ブローカーは複数 listener を持てますが、inter.broker.listener.name は 1 つです。したがって、inter-broker のメカニズムは 1 種に統一し、ユーザー（principal または SCRAM ユーザー）を専用化して監査・権限管理を分離します。

• 外部: EXTERNAL=SASL_SSL + SCRAM または OAUTHBEARER
• 内部: INTERNAL=SASL_PLAINTEXT/SASL_SSL + SCRAM または GSSAPI
• inter-broker は INTERNAL listener を指し、メカニズムは SCRAM か GSSAPI が堅実

典型的なリスナー分離（外部/内部）

トラブル事例と試験頻出ポイント

SCRAM で Authentication failed が出る場合、ユーザー未登録・パスワード不一致・メカニズム不一致（クライアントが PLAIN、ブローカーが SCRAM 限定など）が典型です。listener.name.<listener>.sasl.enabled.mechanisms の制限が効いていないか確認します。

GSSAPI は、KDC 到達不能、clock skew、principal.to.local のマッピング不整合、DNS 逆引き失敗が多いです。klist, kvno, nslookup で切り分け、krb5.conf の realm と KDC を再確認します。OAUTHBEARER はブローカーの検証実装ログを詳細化して、署名鍵/JWKS 取得や aud/iss 検証の失敗点を特定します。

• クライアントとブローカーで sasl.mechanism が一致しているか
• inter-broker 用ユーザー（SCRAM）や principal（Kerberos）を専用化したか
• SASL_PLAINTEXT の利用は限定。外部公開では常に SASL_SSL を選ぶ

よく使う診断コマンド

# SASL/SCRAM: ブローカーの有効メカニズム確認（ログ）
# grep -i "Registered SASL mechanisms" server.log

# SCRAM: 登録ユーザーの確認（環境に応じて）
# kafka-configs.sh --describe --entity-type users --entity-name alice

# Kerberos: チケット/時刻/名前解決
# klist && date && nslookup broker1.example.com

# OAUTH: クライアント側でトークンを取得しデコードして検証
# curl -s -d 'grant_type=client_credentials' https://idp/oauth2/token | jq -r .access_token | cut -d. -f2 | base64 -d | jq

問題で確認

よくある質問