Control Center 用の RBAC の構成¶

Control Center では、ロールベースアクセス制御を使用した認可（role-based access control (RBAC)）がサポートされます。Confluent Platform バージョン 5.3 以降では、RBAC によって開発環境のプラットフォーム全体にきめ細かいセキュリティモデルが提供されます。前のバージョンの Control Center では、読み取り専用かフルアクセスのみという、粗いアクセス制御を提供していました。

RBAC が有効になっていないか、Control Center を Confluent Platform のバージョン 5.3 の前後に対して実行している場合、Control Center は限定アクセスなしで以前と同じように機能します（ただし、control-center-properties ファイルでアクセス制御機能フラグがオフになっていない場合）。RBAC が有効になっていない場合は、Control Center 構成オプションのアクセス制御設定（機能フラグと呼ぶ）によって該当のフラグがある機能へのアクセスを削除できます。対象の機能には、ksqlDB、ライセンスマネージャー、Schema Registry、トピックの検査、ブローカー構成などがあります。使用可能な設定の詳細については、「アクセス制御設定」を参照してください。

RBAC が有効になっている場合、機能設定に代わって RBAC ロールアクセス許可が適用されます。RBAC は、 ACL および LDAP セキュリティと連携して機能します。

通常、Control Center 内の RBAC では、この機能による管理対象のいくつかのリソース、一般的には、この機能で内部ステートを維持するリソース（ライセンス管理、ブローカーメトリクス、アラート）のみに対してアクセス権が適用されます。詳細については、「ロールによる Control Center リソースへのアクセス」を参照してください。Control Center によって管理されるリソースに対する、これ以外の RBAC 適用操作は、ダウンストリームの Apache Kafka®、Schema Registry、Connect、ksqlDB に委任されます。

参考

まず最初に、自動化された RBAC の例をお試しください。Confluent Platform における RBAC の機能を紹介しています。

前提条件¶

メタデータサービスを構成することが必要です。パブリックキーを生成し、RBAC 用に Control Center を構成するために必要な MDS URL を入手します。
ご使用の環境内で Control Center がやり取りする必要のある以下のような、すべてのコンポーネント用に RBAC を構成します。
- Schema Registry。「Schema Registry のロールベースアクセス制御の構成」を参照してください。
- Kafka Connect およびすべてのコネクター。「Connect クラスター用の RBAC の構成」および「コネクター用の RBAC の構成」を参照してください。
- ksqlDB クラスター。「ksqlDB と role-based access control (RBAC)」を参照してください。

Confluent Platform RBAC に関する推奨記事¶

以下のドキュメントを参照し、Confluent Platform での RBAC 機能の詳細を掴んでください。

制限¶

RBAC が有効である場合、Control Center および ksqlDB を Kerberos とともに使用できません。Control Center では、OAUTHBEARER 以外の SASL メカニズムをサポートできないためです。ブラウザーは、トークンベースの偽装を使用した認証に依存します。

注釈

この制限は、Connect および Schema Registry には適用されません。
RBAC が有効になっている場合、UI の自動アップデート機能を使用できません。

ロールによる Control Center リソースへのアクセス¶

Control Center （Kafka、Schema Registry、Connect、ksqlDB）以外のすべてのコンポーネントには、コンポーネント自体によって RBAC が適用されます。Control Center によって RBAC が直接適用されるのは、以下のリソースのみです。

ライセンス管理（Confluent Platform 上でのグローバルな操作）。
ブローカーメトリクス（クラスターごとのシステム正常性）。
アラート（1 つの Control Center インスタンス内のすべてのクラスターに対するグローバルなビュー）。

ロールのスコープ	ライセンス管理	ブローカーのメトリクス	アラート
SystemAdmin	○ [1]	○	○
ClusterAdmin	×	○	○
Operator	×	○	○
ResourceOwner	×	×	○ [2]

[1]	ライセンス管理にアクセスするには、MDS を実行する Kafka クラスター上の `SystemAdmin` ロールが付与されている必要があります。

[2]	トピックまたはコンシューマーグループのリソースオーナーは、そのリソースのトリガーやアクションを作成できます。アラート履歴ページおよび Alerts REST API ページで、起動されたアラートを表示することもできます。

アラートアクセスについて¶

Alerts ページには、すべてのクラスターのトリガー、アクション、アラート履歴がグローバルに表示されます。単一クラスターをスコープとする、Control Center 内の他の機能とは異なり、アラート機能には 1 つの Control Center インスタンスによって管理されているすべてのクラスターが含まれています。

Control Center のアラートは、トリガー、アクション、アラートという 3 つのエンティティで構成されます。

これらのエンティティには、以下の関係があります。

1 つのトリガーに複数のクラスターを関連付けできます（1 対多）。
1 つのアクションに複数のトリガーを関連付けできます（1 対多）。
起動されたアラートには 1 つのトリガーが関連付けられています（1対1）。

これらの関係が、アクセスをフィルター処理する方法に影響します。RBAC が有効になっている場合の各エンティティへのアクセスは、以下のように決定されます。

トリガー: 単一クラスターまたは一連のクラスター上に定義されたなんらかの条件です。トリガーのタイプは、クラスター、ブローカー、トピック、コンシューマーグループです。トリガーアクセスはオールオアナッシングです。つまり、特定のトリガーの読み取り、書き込み、作成、削除ができるか、またはそれらの操作をまったく行えないかです。トリガーにはきめ細かいアクセスレベルはありません。

重要

トリガーは、アラートの RBAC 適用のための基本エンティティです。
アクション: トリガー条件が満たされたときに取るアクションです。メールを送信するか、 Slack または PagerDuty に通知を送信します。トリガーはさまざまなクラスター内のリソースに関連付けできるため、ユーザーは、アクションに関連付けられているすべてのトリガーに対するアクセス権と、それぞれに対応するクラスターに対するアクセス権を持つ場合にのみアクションにアクセス可能です。それ以外の場合は、アクションを表示することもできません。
アラート: トリガーが起動された後でアクションが実行された結果です。Alert History ページに表示されるためには、アラートのトリガーが、アラート履歴に入力するタイプである必要があります（トピックトリガー）。アラート履歴にアクセスできるのは、起動したトリガーへのアクセス権を持つロールがユーザにある場合のみです。ユーザーはアクセス権を持つトリガーのアラート履歴のみを表示できます。

RBAC プレビューバージョン 5.3 では、Alerts UI にアクセスできるユーザーロールは SystemAdmin、ClusterAdmin、Operator のみでした。RBAC バージョン 5.4 では、Alerts アイコンをクリックすることにより、すべてのユーザーが Alerts UI にアクセスできますが、ユーザーが表示または構成できる対象はユーザーのアラートアクセスのレベルによって決まります。アラート処理には 2 つのレベルがあります。

クラスターレベルのアクセス : クラスターおよびブローカーのトリガーが含まれます。クラスターレベルのロールではトピックトリガーを作成するときにトピックパターンマッチングを使用できます。これらのロール（SystemAdmin、ClusterAdmin、Operator ）では、1 つの Control Center インスタンス内の 1 つの特定のクラスターに含まれるすべてのトピックを表示するアクセスが保証されるためです。トピックパターンマッチングを使用することで、指定したパターンと一致する複数のトピックに 1 つのトリガーを適用できます。

注釈

割り当てられたロールによってクラスターレベルのアラートアクセスが提供される場合は、4 つのトリガータイプすべてへのアクセスが含まれます。
リソースレベルのアクセス : コンシューマーグループおよびトピックのトリガーが含まれます。リソースレベルのロールでは、トピックトリガーを作成するときにトピックパターンマッチングを使用できません。これには、すべてのクラスター上のすべてのトピックに対するアクセスが必要とされるためです。ユーザーが 1 つのトピック上の ResourceOwner ロールを持つ場合でも、アクセスを持たない可能性のある複数のトピックに対して、トピックパターンマッチングを使用してトリガーを適用することはできません。ResourceOwner ロールでは、トピックトリガーを作成するときに、リテラルトピック名マッチングを使用できます。リソースレベルのアクセスロールでは、クラスターおよびブローカーのトリガーをセットアップできません。

下表はロール別にアラートアクセス許可をまとめたものです。

アラートトリガーのアクセスレベル¶
ロール	クラスタートリガー	ブローカートリガー	コンシューマーグループトリガー	トピックトリガー	トピックトリガーのパターンマッチング
SystemAdmin	○	○	○	○	○
ClusterAdmin	○	○	○	○	○
Operator	○	○	○	○	○
ResourceOwner	×	×	○	○	○ [3]

[3]	ResourceOwner ロールのみが割り当てられているユーザーは、リテラルトピックマッチングのみを使用できます。パターントピックマッチングは使えません。

Control Center 用の RBAC の構成¶

Control Center 内で RBAC を構成するには、以下の手順に従います。

Control Center プロパティファイル内に関連する RBAC 構成オプションを設定します。
Control Center で管理する追加のすべてのクラスターを追加します（省略可）。「構成の例」を参照してください。
Control Center クラスター、および Control Center インスタンスによって管理される他のすべてのクラスターに対する Control Center ユーザーのロールバインディングを追加します。「Control Center ユーザー用のロールバインディングを追加」を参照してください。
上記以外のサービス（Schema Registry トピック管理、Connect、ksqlDB）用のユーザー権限を構成します。「ロール別権限のテーブル」およびサービスごとのドキュメントを参照してください。

重要

RBAC が有効である場合に、Metrics Reporter およびインターセプターのために必要な追加の構成があります。詳細については、「Confluent Metrics Reporter 用に RBAC を構成する」および「RBAC 用のインターセプターのセットアップ」を参照してください。「既知の問題」も確認してください。

Control Center プロパティファイル内に RBAC 構成オプションを設定する¶

Control Center 内で RBAC を構成するのに必要な設定の例を以下に示します。「RBAC 設定」および、「Control Center 構成リファレンス」にある他のセキュリティカテゴリでの各オプションの説明を参照してください。RBAC 構成設定は各 Control Center プロパティファイル内にあります。詳細については、「Control Center プロパティファイル」を参照してください。

前提条件:

管理者から、パブリックキーのパス、MDS URL、および MDS 用のユーザー名とパスワードを入手します。

マルチクラスター環境用に Control Center を接続する必要のある、すべての補助クラスターのクラスター ID を判別します。「クラスターの識別子について」を参照してください。

重要

5.3 プレビューリリースで RBAC 用に Control Center を構成した場合、Confluent Platform バージョン 5.4 以降では構成オプションが変更されています。構成をアップデートする必要があります。

ご使用の環境に適した Control Center プロパティファイル（<path-to-confluent>/etc/confluent-control-center/control-center.properties ）内で、各構成オプションの以下の行をコメント解除します。プレースホルダーの値は実際の値で置き換えます。
```
 1############################# Control Center RBAC Settings #############################
 2
 3# Enable RBAC authorization in Control Center by providing a comma-separated list of Metadata Service (MDS) URLs
 4#confluent.metadata.bootstrap.server.urls=http://localhost:8090
 5
 6# MDS credentials of an RBAC user for Control Center to act on behalf of
 7# NOTE: This user must be a SystemAdmin on each Apache Kafka cluster
 8#confluent.metadata.basic.auth.user.info=username:password
 9
10# Enable SASL-based authentication for each Apache Kafka cluster (SASL_PLAINTEXT or SASL_SSL required)
11#confluent.controlcenter.streams.security.protocol=SASL_PLAINTEXT
12#confluent.controlcenter.kafka.<name>.security.protocol=SASL_PLAINTEXT
13
14# Enable authentication using a bearer token for Control Center's REST endpoints
15#confluent.controlcenter.rest.authentication.method=BEARER
16
17# NOTE: Must match the MDS public key
18#public.key.path=/path/to/publickey.pem
```
行の説明 :
- 行 4: リソースを認可するための MDS URL です。MDS が複数の環境の場合は、URL をコンマで区切ります。MDS URL が存在することにより、RBAC が有効になっていることが Control Center に伝わります。
- 行 8: Control Center が代行する RBAC ユーザーの Metadata Service (MDS) 認証情報です。
- 行 11 ～ 12: confluent.controlcenter.streams プレフィックスは、Kafka Streams アプリケーション（行 12 のオプションを別の Kafka クラスター用に使用できます）および Kafka クラスターをセットアップするために追加する必要のあるすべての構成を表します。
- 行 15: REST レイヤーを通じて Control Center バックエンドと通信するために必要な認証方式です。OAuth 形式の BEARER 方式が必要です。Control Center フロンドエンドによってユーザーを代理してアクセストークンが取得され、更新が持続されます。HTTP 基本認証ヘッダーは受け入れられません。
- 行 18: REST 認証に必要なパブリックキーのパスです。MDS 上にあるパブリックキーと一致している必要があります。パブリックキーによってトークンがチェックされ、アクセスをリクエストしているユーザーが、システム内の有効なユーザーであることが確認されます。
重要

マルチクラスター環境内の追加のクラスターには、既知の問題により、RBAC を有効にした Kafka への接続が必要です。RBAC が有効になった環境ではメトリクスのみを Control Center に送信できません。管理を完全に有効にする必要があります。詳細については、「Confluent Metrics Reporter」を参照してください。
Confluent Platform を再起動してプロパティファイル構成を有効にします。

Confluent Platform 開発環境で Confluent CLI を使用している場合は、以下のように停止および起動します。
```
confluent local services stop
confluent local services start
```
control-center-dev.properties ファイルは自動で入力されます。

Control Center ユーザー用のロールバインディングを追加¶

ロールバインディングを追加して Control Center ユーザーにロールをバインドします。Control Center 内の RBAC では、Control Center クラスターと呼ばれる Kafka クラスター上でユーザーが Control Center ステートを持続することが必要です。環境内の各 Kafka クラスター用にロールバインディングを追加します。

前提条件:: Control Center および、Control Center によって管理される他のすべての Kafka クラスターの Kafka クラスター ID を判別します。「クラスターの識別子について」を参照してください。

注釈

以下の例の <kafka-id> は、Control Center 用のクラスター ID で置き換えます。構文エラーを回避するため、コピーアンドペーストしたコマンドからバックスラッシュを削除します。

confluent iam rbac role-binding create \
--principal User:<c3-principal> \
--role SystemAdmin \
--kafka-cluster-id <kafka-id>

重要

既知の問題があるため、ロールは SystemAdmin である必要があります。

ちなみに

CLI ではなく Control Center UI を使用してロール割り当てを追加するか、ロール割り当てを削除します。

ロールの権限¶

以下のロール権限のテーブルは、ユーザーに付与する必要のあるアクセス許可のためのガイドラインとして使用します。

Control Center でのロール別トピック管理権限¶

Control Center 内のトピック管理エリアには複数の機能が含まれています。

概要: トピックの生成および消費メトリクスへのアクセスです。ユーザーは、トピックに対するアクセスとブローカーメトリクスに対する適切なロールを持つ場合、メトリクスを表示できます。「ロールによる Control Center リソースへのアクセス」を参照してください。
メッセージブラウザー: トピックに対する読み取りアクセスを持つユーザーはメッセージをブラウズできます。
スキーマ: アクセスはサブジェクトの読み取り、書き込み、および記述を行う権限に基づきます。
構成: Describe configs 権限では、Configuration ページにアクセスできます。

トピック、スキーマサブジェクト、およびコンシューマーグループは、プリンシパルのアクセス権に基づいて Control Center 内でフィルター処理されます。

Schema Registry では、Read、Write、Delete など、ユーザーが持つサブジェクト操作の定義を記述する /permissions API エンドポイントを提供しています。

注釈

トピックを追加する能力はトピック名によって適用されます。トピックの作成はフォーム送信時にゲートされます。つまり、ユーザーは Add topic ボタンをクリックできますが、トピック名による制限であるためこのボタンは常時表示されることから、ユーザーが事前にユーザーの権限を知ることはできません。

トピック検査（別名はメッセージブラウザー）WebSocket 接続はプロキシ処理されます。

トピック管理（クラスタースコープ）¶
ロール	作成	Delete	Read	Write	Describe	Describe configs	Alter	Alter configs	Describe access	Alter access
super.user	○	○	○	○	○	○	○	○	○	○
SystemAdmin	○	○	○	○	○	○	○	○	○	○
UserAdmin	×	×	×	×	×	×	×	×	×	×
ClusterAdmin	○	○	×	×	○	○	○	○	×	×
Operator	×	×	×	×	×	×	×	×	○	×
SecurityAdmin	×	×	×	×	×	×	×	×	○	×

トピック管理（リソーススコープ）¶
ロール	作成	Delete	Read	Write	Describe	Describe configs	Alter	Alter configs	Describe access	Alter access
ResourceOwner	○	○	○	○	○	○	○	○	○	○
DeveloperRead	×	×	○	×	○	×	×	×	×	×
DeveloperWrite	×	×	×	○	○	×	×	×	×	×
DeveloperManage	○	○	×	×	○	○	×	×	×	×

注釈

RBAC セキュリティロールは本質的に付加的です。複数のロールを割り当てられているユーザーは、割り当てられたすべてのロールに関連付けられた権限のまとまりを持ちます。

トピックロールバインディングの例¶

単一ユーザーの単一トピックに対する読み取りアクセスを追加する :

confluent iam rbac role-binding create \
--principal User:<user-name> \
--role DeveloperRead \
--resource Topic:<topic_name> \
--kafka-cluster-id <kafka_cluster_id>

このユーザーは All topics ページでこのトピックを表示できます。

単一ユーザーの単一トピックに対する読み取りアクセスを削除する :

confluent iam rbac role-binding delete \
--principal User:<user-name> \
--role DeveloperRead \
--resource Topic:<topic_name> \
--kafka-cluster-id <kafka_cluster_id>

このユーザーは All topics ページでこのトピックを表示できなくなりました。

Control Center でのロール別コネクター権限¶

コネクターは、プリンシパルのアクセス権に基づいて Control Center 内でフィルター処理されます。Confluent Platform バージョン 5.3 以降では、Kafka Connect のリクエストは Control Center によってプロキシされるようになりました。

Connect では、ユーザーが自分のトークンスコープに基づいて実行できるすべての操作を Control Center に通知する /permissions API エンドポイントを提供しています。この permissions エンドポイントによって、Control Center ウェブインターフェイスでコネクターを追加、一時停止して再開、および削除する能力が決まります。コネクターを追加する能力はコネクター名によって適用されます。

コネクターのスケーリングを行うにはコネクター構成を編集します。コネクター構成の編集は、コネクター構成を表示または変更する能力によって制御されます。Control Center では、構成変更が送信（つまり起動）されるまで、スケールの能力をチェックしません。

注釈

RBAC が有効にされている場合、Control Center 内にはコネクター構成の読み取り専用ビューはありません。

ロール別コネクター権限（クラスタースコープ）¶
ロール	作成	Read config	Read status	Pause	Resume	Scale	Delete	Configure	Describe access	Alter access
super.user	○	○	○	○	○	○	○	○	○	○
SystemAdmin	○	○	○	○	○	○	○	○	○	○
UserAdmin	×	×	×	×	×	×	×	×	×	×
ClusterAdmin	○	○	○	○	○	○	○	×	×	×
Operator	×	×	○	○	○	○	×	×	×	×
SecurityAdmin	×	×	×	×	×	×	×	×	○	×

ロール別コネクター権限（リソーススコープ）¶
ロール	作成	Read config	Read status	Pause	Resume	Scale	Delete	Configure	Describe access	Alter access
ResourceOwner	○	○	○	○	○	○	○	○	○	○
DeveloperRead	×	○	○	×	×	×	×	×	×	×
DeveloperWrite	×	×	○	×	×	×	×	○	×	×
DeveloperManage	○	×	○	○	○	○	×	×	×	×

Connect での RBAC の詳細については、「Connect クラスター用の RBAC の構成」および「コネクター用の RBAC の構成」を参照してください。

コネクターロールバインディングの例¶

単一ユーザーの単一コネクターに対する読み取りアクセスを追加 :

confluent iam rbac role-binding create \
--principal User:<user-name> \
--role DeveloperRead \
--resource Connector:<connector_name> \
--kafka-cluster-id <kafka_cluster_id> \
--connect-cluster-id <connect_cluster_id>

このユーザーは Connectors ページでこのコネクターを表示できます。

単一ユーザーの単一コネクターに対する読み取りアクセスを削除する :

confluent iam rbac role-binding delete \
--principal User:<user-name> \
--role DeveloperRead \
--resource Connector:<connector_name> \
--kafka-cluster-id <kafka_cluster_id> \
--connect-cluster-id <connect_cluster_id>

このユーザーは Connectors ページでこのコネクターを表示できなくなります。

connect-statuses 内部トピックへのアクセスを付与

重要

Kafka クラスター上のアクセス許可を持たないユーザーが Control Center 内で Connect を使用するには、connect-statuses 内部トピック上の DeveloperRead ロールを付与することをお勧めします。詳細については「既知の問題」を確認してください。

confluent iam rbac role-binding create \
--principal User:<user-name> \
--role DeveloperRead \
--resource Topic:connect-statuses \
--kafka-cluster-id <kafka_cluster_id>

Control Center のフィールドにコネクターを追加する際の考慮事項¶

Control Center 内で RBAC が有効にされている場合、現在デフォルトフィールドとしては提供されていない、コネクターを構成するために必要な追加のフィールド（JAAS 構成など）があります。Additional Properties ペインでは、コネクターを追加するときに必要なすべてのプロパティを追加できます。

注釈

ユーザーは、対象のトピックに対するアクセス許可を持たない場合でも topics フィールド（Which topics do you want to get data from? ペイン内）にトピック名を入力できます。これにより、ユーザーはこのような状況下でコネクターを構成できます。

ちなみに

Confluent Platform バージョン 5.4 以降では、Control Center 内でのコネクターの追加操作が改善されました。詳細については、「コネクターの追加（RBAC 環境）」を参照してください。

Control Center でのロール別 ksqlDB 権限¶

Control Center での ksqlDB GUI へのアクセスは、ksqlDB クラスター上の CONTRIBUTE 操作によって決定されます。CONTRIBUTE により、ksqlDB クラスターに接続する能力が付与されます。

Control Center 内の HTTP リクエストは ksqlDB サーバーにプロキシされます。以降の WebSocket 接続は ksqlDB に対して直接行われます。

ロール別 ksqlDB contribute 権限（クラスタースコープ）

ロール	Contribute
super.user	○
SystemAdmin	○
UserAdmin	×
ClusterAdmin	○
Operator	×
SecurityAdmin	×

ロール別 ksqlDB contribute 権限（リソーススコープ）

ロール	Contribute
ResourceOwner	○
DeveloperRead	×
DeveloperWrite	○
DeveloperManage	×

ksqlDB RBAC の詳細については、「ksqlDB と role-based access control (RBAC)」を参照してください。

ksqlDB ロールバインディングの例¶

単一ユーザーの単一 |ksqldb| クラスターに対する DeveloperWrite アクセスを追加する :

confluent iam rbac role-binding create \
--principal User:<sam> \
--role DeveloperWrite \
--kafka-cluster-id <kafka-id>  \
--ksql-cluster-id <ksql-id>  \
--resource KsqlCluster:ksql-cluster

ksqlDB のロールバインディングを扱う他の例については、「ksqlDB サーバーを起動するためのロールの割り当て」および「ksqlDB アプリケーションに参加するためのロールの割り当て」を参照してください。

重要

ユーザーがクエリを実行する必要のあるトピックへのアクセスをユーザーに付与します。詳細については「既知の問題」を確認してください。

Control Center 内での RBAC に関する既知の問題¶

外部クラスターへの Control Center 接続¶

各外部クラスターへの直接アクセスが必要です。（SEC-239、MMA-4394）。 RBAC が有効になっている場合、Control Center では、各クラスター上で管理が有効にされている必要があります。つまり、RBAC 環境内で Control Center が適切に動作するためには、構成されている Metrics Reporter およびインターセプターが直接接続を持つ必要があります。この制限により、各外部クラスターの confluent.controlcenter.kafka.<name>.bootstrap.servers および confluent.controlcenter.kafka.<name>.security.protocol を構成の例にあるように設定する必要があります。

重要

RBAC が有効である場合に、Metrics Reporter およびインターセプターのために必要な追加の構成があります。詳細については、「Confluent Metrics Reporter 用に RBAC を構成する」および「RBAC 用のインターセプターのセットアップ」を参照してください。

Control Center service principal ロール¶

Control Center のサービスプリンシパルには SystemAdmin アクセスが必要です（MMA-4634、MMA-4650）。 Control Center ユーザーは、各クラスター上で特権ユーザー SystemAdmin としてセットアップされる必要があります。コンシューマーラグ用の基盤となるアーキテクチャにより、すべてのコンシューマーグループへのユーザーアクセスと、コンシューマーラグ用のコンシューマーグループアラートのための継続的なサポートを保証するために、昇格された特権が必要です。コンシューマーラグのオフセットは現在 Metrics Reporter から取得されません。

Connect および ksqlDB クラスターのユーザーアクセス¶

Connect および |ksqldb| では、基盤の Kafka クラスターに対して少なくとも最小のユーザーアクセスを必要とします（MMA-4756）。

RBAC が有効になっている場合、Control Center 内で Connect または ksqlDB を参照するには、ユーザーは基盤の Kafka クラスターへのアクセスを必要とします。

Kafka クラスター上のアクセス許可を持たないユーザーが Control Center 内で Connect を使用するには、connect-statuses 内部トピック上の DeveloperRead ロールを付与することをお勧めします。
SQL クエリを実行するには、ユーザーは Kafka クラスターへの一定レベルのアクセスが必要です。Control Center ウェブインターフェイス内で ksqlDB を表示できるように、クエリを実行する必要のあるトピックに対するアクセスをユーザーに付与します。

このいずれのケースでも、基盤の Kafka クラスターに対するアクセスをユーザーに付与すると、ユーザーは Control Center 内の Connect ページおよび ksqlDB ページにアクセスできます。

Control Center 内の RBAC のトラブルシューティング¶

問題 : Topics の Consumption パネルでストリームモニタリングデータを表示しようとするとアクセスメッセージが出ます。これは、% message consumed チャートと end-to-end latency チャートに適用されます。

チャートを表示するにはトピックおよびトピックのすべてのコンシューマーグループへのアクセスを必要とするという RBAC メッセージ¶

背景 : ユーザーがトピック上のストリームモニタリングデータを表示しようとします。このユーザーはトピックに対するアクセスを持ちますが、1 つのトピックから読み取っている一部のコンシューマーグループに対するフルアクセスを持ちません。

是正措置 : 該当のアクセスを持つ必要のあるユーザーであれば、1 つのトピックから読み取っているすべてのコンシューマーグループに対するアクセスをユーザーに付与します。

RBAC を無効にする¶

ご使用の環境で Control Center とやり取りするすべてのコンポーネントで RBAC を無効にする必要があります。

Control Center 内で RBAC を無効にするには、confluent.controlcenter.metadata.urls 設定をコメントアウトし、Control Center を再起動します。