Confluent RBACのロール設計とスコープ実務

RBACは「誰に」「どの範囲で」「何を許可するか」を明示する設計がすべてです。本稿はConfluentの公式ドキュメントに沿った安定概念（スコープ階層と代表ロール）を軸に、CCAAKで問われやすい最小権限設計とスコープ選定の実務パターンをまとめます。

クラウド（Confluent Cloud）とオンプレ/自己管理（Confluent Platform）で細部は異なりますが、スコープ階層とロール割り当ての考え方は共通です。バージョン依存の詳細は公式ドキュメントを併読してください。

RBACの基本とスコープ階層

ConfluentのRBACは、ユーザーやサービスアカウント（プリンシパル）に対して、特定のスコープ内でロールを結び付ける仕組み（ロールバインディング）です。スコープは一般に、Organization、Environment、各種クラスタ（Kafka、Schema Registry、ksqlDB、Connect）、およびリソース（Topic、Consumer Group、TransactionalId、Subject）という階層で表現されます。

上位スコープでの管理ロールは、そのスコープ配下の対象を包括的に管理できます。一方、開発者ロール（DeveloperRead/Writeなど）は通常、クラスタまたは個別リソースに限定して最小権限で付与します。Confluent Cloudでは組織・環境・各クラスタのIDを明示してロールバインディングを作成します。Confluent PlatformではMDSを介して同等の概念を適用します。

• スコープ階層の基本: Organization > Environment > Cluster > Resource
• 主な対象サービス: Kafka、Schema Registry、ksqlDB、Connect
• プリンシパル: ユーザー（人）とサービスアカウント（アプリ）

スコープ階層のイメージ

Organization
  └─ Environment (env-xxxxx)
       ├─ Kafka Cluster (lkc-xxxxx)
       │    └─ Resources: Topic/Group/TransactionalId
       └─ Schema Registry (lsrc-xxxxx)
            └─ Resources: Subject

IDの確認と前提設定（Confluent Cloud CLI例）

confluent login
confluent environment list
confluent environment use env-xxxxx
confluent kafka cluster list
confluent kafka cluster use lkc-xxxxx
confluent sr cluster list
# SR Cluster ID (例: lsrc-xxxxx) を控える

最小権限のロール設計

運用者ロール（Organization/Environment/Clusterの管理権限）はプラットフォームチームに限定し、アプリケーションには原則としてリソース単位でDeveloperRead/WriteまたはResourceOwnerのみを付与します。SecurityAdmin（または同等のロール）をロール付与の責任者にして、職務分離を徹底します。

プロデューサは出力トピックにDeveloperWrite、コンシューマは入力トピックにDeveloperReadと使用するコンシューマグループに対する必要最小限の権限を与えます。トピック設定やスキーマ運用をアプリ側で行う場合のみResourceOwnerやSchemaRegistryの管理ロールを検討します。

• 職務分離: 環境・クラスタ管理とアプリ権限付与を分離
• 最小権限: DeveloperRead/Writeをリソース単位で付与
• 所有権: チーム単位でResourceOwnerを限定的に使用

職務分離の最小構成

[Platform]
  Org/Env/Cluster Admins
      |
      | 付与(最小権限)
      v
  [App Teams]
    SA(producer): Topic-X -> DeveloperWrite
    SA(consumer): Topic-X -> DeveloperRead; Group-G -> DeveloperRead

最小権限でのロールバインディング作成（Cloud例）

# プロデューサ用（orders への書き込み）
confluent iam role-binding create \
  --principal User:sa-orders-producer \
  --role DeveloperWrite \
  --resource Topic:orders \
  --kafka-cluster lkc-xxxxx \
  --environment env-xxxxx

# コンシューマ用（orders から読み取り、コンシューマグループ cg-orders）
confluent iam role-binding create \
  --principal User:sa-orders-consumer \
  --role DeveloperRead \
  --resource Topic:orders \
  --kafka-cluster lkc-xxxxx \
  --environment env-xxxxx
confluent iam role-binding create \
  --principal User:sa-orders-consumer \
  --role DeveloperRead \
  --resource Group:cg-orders \
  --kafka-cluster lkc-xxxxx \
  --environment env-xxxxx

KafkaリソースとSchema Registryのスコープ設計

Kafkaの典型リソースはTopic、Consumer Group、TransactionalIdです。トピック作成・削除・設定変更は原則として運用側（ClusterAdminやResourceOwner）に限定し、アプリ側は既存トピックへの読み書き（DeveloperRead/Write）に留めます。TransactionalIdはトランザクション機能を使うプロデューサに対して、必要時のみ付与します。

Schema Registryではクラスター単位の管理（SchemaRegistryAdmin）と、Subject単位の所有（ResourceOwner）や更新権限（DeveloperWrite）を分けます。アプリがスキーマ更新を行う場合は対象Subjectに限定した権限を付与します。

• トピック作成・削除は運用ロールで集約
• アプリは必要なTopic/Group/Subjectにのみ権限を付与
• トランザクション利用時はTransactionalIdの権限を個別付与

Kafka/SRリソース単位の割り当て

Kafka Cluster (lkc-xxxxx)
  ├─ Topic: teamX.orders-in   -> SA(consumer): DeveloperRead
  ├─ Topic: teamX.orders-out  -> SA(producer): DeveloperWrite
  └─ Group: cg-teamX-orders   -> SA(consumer): DeveloperRead
Schema Registry (lsrc-xxxxx)
  └─ Subject: teamX.orders-value -> SA(producer): DeveloperWrite

Schema RegistryのSubject権限付与（Cloud例）

# スキーマ更新を行うプロデューサにSubject更新権限を付与
confluent iam role-binding create \
  --principal User:sa-orders-producer \
  --role DeveloperWrite \
  --resource Subject:teamX.orders-value \
  --schema-registry-cluster lsrc-xxxxx \
  --environment env-xxxxx

環境間・テナント設計と命名規約

マルチ環境では、Environmentをdev/stg/prodで分離し、各環境にKafka/SRを配置します。サービスアカウントは環境ごとに分けると権限の見通しが良くなります（同一SAを複数環境で使うと、権限の拡散と監査の複雑化を招きやすい）。

トピックやSubjectの命名にチーム/ドメイン接頭辞を用いて所有境界を明確化し、ResourceOwnerの配布範囲を制限します。命名規約は運用ルールとして文書化し、ロールバインディングの標準テンプレート化（GitOps）と組み合わせると管理が安定します。

• サービスアカウントは原則「アプリ×環境」で発行
• トピック/Subjectにチーム接頭辞を付けて所有を明示
• ロールバインディングはテンプレ化しレビュー可能に

環境とクラスタの対応

Organization
  ├─ Env: dev
  │    ├─ Kafka: lkc-dev
  │    └─ SR:   lsrc-dev
  └─ Env: prod
       ├─ Kafka: lkc-prod
       └─ SR:    lsrc-prod

同一アプリを複数クラスタに最小権限で割り当て（Cloud例）

# dev環境
confluent iam role-binding create \
  --principal User:sa-orders-producer-dev \
  --role DeveloperWrite \
  --resource Topic:teamX.orders \
  --kafka-cluster lkc-dev \
  --environment env-dev

# prod環境
confluent iam role-binding create \
  --principal User:sa-orders-producer-prod \
  --role DeveloperWrite \
  --resource Topic:teamX.orders \
  --kafka-cluster lkc-prod \
  --environment env-prod

監査・運用・移行の実務ポイント

監査では、誰にどのロールをいつ付与/剥奪したか、環境・クラスタ・リソースのスコープを含めて追跡します。Confluent Cloudでは監査ログ機能を利用し、定期的にロールバインディング一覧をエクスポートして棚卸しします。

Confluent Platformからの移行や従来ACLからの段階的移行では、RBACとACLの管理境界を明確にし、対象プリンシパルをRBACに切り替えたら直接ACLを更新しない運用ルールに統一します。トラブル時はまずスコープ不一致（env/cluster/subject/名前の綴り）を疑います。

• 棚卸し: ロールバインディングを定期エクスポート
• 監査: 付与主体（SecurityAdmin）と申請記録を紐付け
• 移行: RBAC切替後は直接ACL更新を不可にする運用ルール

認可の流れ（高レベル）

Client -> AuthN (IDP/Keys)
      -> RBAC Authorizer (MDS/Cloud IAM)
      -> Resource check (Scope + Role)
      -> Allow / Deny

棚卸しと確認（Cloud CLI例）

# バインディング一覧（環境/クラスタで絞り込み）
confluent iam role-binding list --environment env-xxxxx --kafka-cluster lkc-xxxxx
confluent iam role-binding list --environment env-xxxxx --schema-registry-cluster lsrc-xxxxx

# 単体検証（例: 簡易プロデュース/コンシューム）
confluent kafka topic produce orders --value "test" --environment env-xxxxx --cluster lkc-xxxxx
confluent kafka topic consume orders --from-beginning --environment env-xxxxx --cluster lkc-xxxxx

CCAAK向け試験対策チェックリスト

出題の多くは「どのスコープで、どのロールを、どのプリンシパルに割り当てるか」を正しく選べるかに集約されます。EnvironmentAdminとClusterAdmin、ResourceOwnerとDeveloperWrite/Readの違いと適用範囲を素早く判断できるようにしておきます。

KafkaとSchema Registryはスコープが別である点、SubjectはSRのリソースである点、コンシューマ動作にはTopicとGroupの双方が関与する点を押さえてください。

• スコープ階層を上から言えるようにする
• トピック書き込みはDeveloperWrite、スキーマ更新はSR側の権限
• グループ操作はGroupリソースへの権限が別途必要

記憶のフック（階層と責務）

Org -> Env -> Cluster(Kafka/SR) -> Resource(Topic/Group/Subject)
Admin roles: 上位で管理
Dev roles: リソースで最小権限

直前チートシート（Cloud例）

# Kafka: 書き込み
confluent iam role-binding create --principal User:sa --role DeveloperWrite --resource Topic:orders --kafka-cluster lkc --environment env
# SR: スキーマ更新
confluent iam role-binding create --principal User:sa --role DeveloperWrite --resource Subject:orders-value --schema-registry-cluster lsrc --environment env
# Group: 消費
confluent iam role-binding create --principal User:sa --role DeveloperRead --resource Group:cg-orders --kafka-cluster lkc --environment env

問題で確認

よくある質問