Kafka の ACL 設計ガイド: Principal・Resource・Operation を正しく組み合わせる

Kafka のアクセス制御は Principal（誰）・Resource（何に）・Operation（何をする）・Permission（許可/拒否）・Pattern（一致方法）の積み上げで決まります。試験や実務で迷いやすいのは、この5要素の組み合わせと評価順序です。

この記事では公式ドキュメントに基づき、設計の勘所と CLI 例を最小構成でまとめます。CCAAK を意識しつつ、現場でそのまま使える命名・前方一致・Deny ルールの扱いを具体化します。

ACL の基礎: 5つの要素と安全な初期設定

Kafka の ACL は、Principal（User:app、CN=client、krb5 の principal など）、Resource（Topic/Group/Cluster/TransactionalId…）、Operation（READ/WRITE/CREATE…）、Permission（ALLOW/DENY）、Pattern（LITERAL/PREFIXED）の組み合わせで定義します。評価は基本的に「一致した DENY があれば拒否、なければ一致した ALLOW があれば許可、なければ拒否」です。

初期運用では StandardAuthorizer（最近の Kafka 既定の Authorizer）を有効化し、スーパーユーザ（運用用）を明示、業務アプリには最小権限のみを付与するのが安全です。

• 主な Resource: Topic, Group, Cluster, TransactionalId
• 代表的 Operation と意味: READ（取得/グループ参加・コミット）, WRITE（書き込み）, CREATE/DELETE（作成/削除）, DESCRIBE（メタデータ参照）, ALTER/ALTER_CONFIGS（変更）, DESCRIBE_CONFIGS（設定参照）, IDEMPOTENT_WRITE（冪等プロデュース許可）
• Pattern: LITERAL（完全一致）, PREFIXED（前方一致）。ワイルドカード "*" も使用可（広範囲に効くため取り扱い注意）
• DENY は強力です。例外的な遮断に限定し、通常は ALLOW ベースで設計します

基本の ACL 付与（ブローカー3.x以降は --bootstrap-server を推奨）

bin/kafka-acls.sh \
  --bootstrap-server broker1:9092 \
  --add --allow-principal User:app-writer \
  --operation WRITE --operation DESCRIBE \
  --topic payments

# コンシューマ（トピックREAD + グループREAD）
bin/kafka-acls.sh \
  --bootstrap-server broker1:9092 \
  --add --allow-principal User:app-reader \
  --operation READ --topic payments \
  --operation READ --group pay-consumer

Principal 設計: サービスアカウントと命名規則

Principal は認証層から渡される実体で、SASL/SCRAM のユーザ名、SASL/PLAIN のユーザ、mTLS の証明書サブジェクト（CN 等）、Kerberos のプリンシパルが一般的です。ACL は最終的に User:xxx といった文字列で評価されます。

設計上はアプリ/役割単位のサービスアカウントを分け、環境とシステム名を接頭辞に入れて衝突・横断的権限付与を避けます。障害調査のため人間利用の Principal とサービス用を必ず分離しましょう。

• 命名例: prod-appA-writer, stg-appA-reader のように env-system-role を含める
• 1アプリ1アカウント（共有禁止）、回転・失効を容易にする
• mTLS の場合は証明書の CN/OU → Principal 変換ルールを固定化
• スーパーユーザは super.users=User:ops-admin のように限定列挙

SASL/SCRAM のユーザ作成と ACL 付与（例）

# SCRAM ユーザ作成（ブローカー側）
bin/kafka-configs.sh --bootstrap-server broker1:9092 \
  --alter --add-config 'SCRAM-SHA-512=[password=secret-pass]' \
  --entity-type users --entity-name prod-appA-writer

# 書き込み用 ACL
auth_user=User:prod-appA-writer
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal "$auth_user" \
  --operation WRITE --operation DESCRIBE \
  --topic payments-orders

Resource 設計: 名前空間と PREFIXED の使いどころ

トピック/グループは名前空間を切ると ACL 設計が単純になります。システム名-ドメイン-用途-環境 などの規則で統一し、前方一致（PREFIXED）を使ってまとめて許可するのが実務的です。

ただし PREFIXED は範囲が広くなりがちです。Deny と組み合わせて微修正するのではなく、許可側のプレフィックス設計を見直すのが安全です。

• 命名例: payments-orders-prod, payments-refunds-prod, analytics-raw-stg
• グループ名も同様に env-system-role を含める: prod-appA-consumer
• 同一接頭辞に運用系と業務系を混在させない（人為ミス抑止）
• トピックの自動作成は原則無効化し、Admin 経由で管理

名前空間と前方一致 ACL のイメージ

PREFIXED ACL の付与（トピック/グループにまとめて適用）

bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal User:prod-appA-reader \
  --resource-pattern-type prefixed \
  --operation READ --topic payments- \
  --operation READ --group prod-appA-

Operation 設計: 最小権限セットの定石

プロデューサ/コンシューマ/管理者など典型ロールごとに必要な Operation はほぼ定型です。冪等プロデューサやトランザクションを使う場合は Cluster/TransactionalId への付与が別途必要になります。

本番では auto.create.topics.enable は無効が通例のため、トピック作成は管理用 Principal に限定しましょう。

• Producer: WRITE + DESCRIBE（対象 Topic）。冪等は IDEMPOTENT_WRITE（Cluster）を追加
• Transactional producer: 上記 + WRITE（対象 TransactionalId）
• Consumer(Group管理あり): READ（対象 Topic）+ READ（対象 Group）
• Topic 管理者: CREATE/DELETE/ALTER/DESCRIBE/ALTER_CONFIGS/DESCRIBE_CONFIGS（対象 Topic）。必要に応じて Cluster の CREATE
• 監視用途: DESCRIBE / DESCRIBE_CONFIGS のみを最小付与

典型ロールの ACL 例

# 冪等プロデューサ（idempotent）
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal User:prod-appA-writer \
  --operation WRITE --operation DESCRIBE --topic payments-orders-prod
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal User:prod-appA-writer \
  --operation IDEMPOTENT_WRITE --cluster

# トランザクション（transactional.id=tx-payments）
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal User:prod-appA-writer \
  --operation WRITE --transactional-id tx-payments

# コンシューマ（グループ単位）
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal User:prod-appA-reader \
  --operation READ --topic payments-orders-prod \
  --operation READ --group prod-appA-consumer

評価順序と Deny の扱い: 衝突時はどうなるか

Kafka の Authorizer は一致した DENY が1つでもあれば拒否、DENY がなければ一致した ALLOW が1つでもあれば許可、どちらもなければ拒否という単純なルールです。パターンの“より具体的”といった優先度はありません。広い PREFIXED の ALLOW に対して、より狭い LITERAL の DENY を置くと、DENY が常に優先して遮断されます。

例外として、ブローカー設定の super.users に列挙された Principal は ACL をバイパスします。運用者専用に限定し、監査ログを必ず有効化してください。

• Deny は最終手段。誤設計のカバーに使わず、名前空間と ALLOW 側を見直す
• パターンが複数一致しても Deny > Allow > Default deny
• 監査: authorizer.log.enabled を有効化し、拒否イベントを監視

Deny の具体例（特定トピックだけ遮断）

# 広い許可（payments-* を READ 許可）
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal User:prod-appA-reader \
  --resource-pattern-type prefixed \
  --operation READ --topic payments-

# ただし refunds は読ませない（Deny が優先）
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --deny-principal User:prod-appA-reader \
  --operation READ --topic payments-refunds-prod

運用・検証とガバナンス: 変更の安全弁

ACL は即時反映されるため、誤設定の影響が大きく出ます。変更前に影響範囲を可視化し、命名規則と付与方針をコード化（IaC）してレビュー可能にするのが安全です。Confluent 環境なら RBAC 併用も検討できますが、試験ではベーシックな ACL 評価が中心です。

監査では、拒否ログ・誰がどの操作で拒否されたか・どの ACL にマッチしたかの突合を日次で行います。アプリ移行時は、PREFIXED を使って一時的に広めに許可し、移行完了後に範囲を絞り込むのが現実的です。

• 現状確認: kafka-acls.sh --list で Principal/Resource ごとに棚卸し
• 変更は Pull Request ベースで。命名規則と一体管理
• 本番直前の deny テスト: ダミー Principal で遮断確認
• 環境分離: stg と prod の接頭辞・クラスターを分離

棚卸し・削除・安全なロールバック

# 一覧
bin/kafka-acls.sh --bootstrap-server broker1:9092 --list

# 特定 ACL の削除（間違いを戻す）
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --remove --allow-principal User:prod-appA-reader \
  --operation READ --group prod-appA-consumer

# 広い PREFIXED 許可を一時付与して移行を助け、後で削る
bin/kafka-acls.sh --bootstrap-server broker1:9092 \
  --add --allow-principal User:migration-helper \
  --resource-pattern-type prefixed --operation READ --topic payments-

問題で確認

よくある質問