ロールベースアクセス制御の事前定義されたロール¶
ロールは、ユーザーが実行できるタスクを定義する、アクセス許可の集合体です。Confluent Platform には、事前定義されたロールが用意されています。これらは、特定のリソースに対するきめ細かいアクセス許可を実現し、Confluent Platform 全体のアクセス制御を簡素化するために役立ちます。新しいロールを作成または定義すること、また事前定義されたロールのアクセス許可を変更することはできません。個々のユーザーに、複数のロールを割り当てることができます。事前定義されたロールを使用して、ACL で構成されているアクセス拒否(DENY)をオーバーライドすることはできません。
クラスターレベル (Kafka クラスター、Schema Registry クラスター、ksqlDB クラスター、または Connect クラスター)でロールが割り当てられている場合は、そのロールが割り当てられているユーザーが、クラスター内のすべてのリソースにアクセスできることを意味します。たとえば、Kafka クラスターの ClusterAdmin
は、Confluent Control Center アラートにアクセスできます。各クラスタータイプには、対応するリソースタイプがあります。たとえば、ResourceOwner
ロールをリソースタイプ KsqlCluster:ksql-cluster
または Cluster:kafka-cluster
に割り当て、ksqlDB または Kafka クラスターに対するすべての ResourceOwner
権限をユーザーに提供できます。
リソースレベル でロールが割り当てられている場合、このロールが割り当てられているユーザーは、ロールバインディングで定義されている特定のリソースのみにアクセスできます。
RBAC ロールとロールバインディングを割り当てることができるリソースタイプは次のとおりです。
- Kafka クラスター
- トピック
- コンシューマーグループ
- トランザクション ID
- Schema Registry クラスター
- Schema Registry サブジェクト
- ksqlDB クラスター
- Connect クラスター
- コネクター
Confluent Platform には、以下の事前定義されたロールが用意されています。
ロール名 | ロールのスコープ | 他のロールバインディングの表示 | ロールバインディングの管理 | モニタリング | リソースの読み取り | リソースの書き込み | リソースの管理 |
---|---|---|---|---|---|---|---|
super.user | クラスターレベル | ○ | ○ | ○ | ○ | ○ | ○ |
SystemAdmin | クラスターレベル | ○ | ○ | ○ | ○ | ○ | ○ |
ClusterAdmin | クラスターレベル | × | × | ○ | ○ | ○ | ○ |
UserAdmin | クラスターレベル | ○ | ○ | × | × | × | × |
SecurityAdmin | クラスターレベル | ○ | × | × | × | × | × |
AuditAdmin | クラスターレベル | × | × | × | × | × | ○ (1) |
Operator | クラスターレベル | × | × | ○ | × | × | ○ (2) |
ResourceOwner | リソースレベル | ○ | ○ | × | ○ | ○ | ○ |
DeveloperRead | リソースレベル | × | × | × | ○ | × | × |
DeveloperWrite | リソースレベル | × | × | × | × | ○ | × |
DeveloperManage | リソースレベル | × | × | × | × | × | ○ |
- 注意事項:
- AuditAdmin ロールでは、監査ログ構成を作成および管理するための十分なアクセスが許可されます。
- Operator によるリソースの管理では、Operator はコネクターの一時停止、再開、およびスケーリングのみを行うことができます。
- super.user
super.user
の目的は、最初に別のユーザーにSystemAdmin
ロールを付与できるブートストラップユーザーを設定することです。厳密には、
super.user
は事前定義されたロールではありません。これは、Metadata Service (MDS) クラスター内のすべてのリソースへのフルアクセス権限を持つユーザーを定義するserver.properties
属性です。super.user
は、他のクラスターのリソースにアクセスできません(他のクラスターでもsuper.user
として構成されている場合を除く)。super.user の主な用途は、Confluent Platform をブートストラップし、SystemAdmin を割り当てることです。MDS クラスターで、super.user
は他のすべてのクラスターのロールバインディングを作成できます。super.user
によって付与されるアクセス許可は、super.user
属性が指定されているブローカーにのみ適用され、他のブローカー、クラスター、Confluent Platform コンポーネントには適用されません。super.user
として定義されたユーザーには認可が適用されません。このロールは限られた数のユーザー(ブートストラップを担当する 1 〜 2 人のユーザーなど)のみに割り当てることを強くお勧めします。- SystemAdmin
クラスター(ksqlDB クラスター、Kafka クラスター、または Schema Registry クラスター)内のすべてのスコープ付き リソース へのフルアクセスを提供します。
このロールは、初期セットアップ用にフルアクセス許可を必要とする場合や、本稼働環境のインスタンスでどうしても必要な場合に緊急の問題に対処するという目的に限定して、限られた数のユーザー(クラスターごとに 1 ~ 2 人)のみに割り当てることを強くお勧めします。小規模なテストおよび開発のユースケースで使用する場合や、主に単一テナントである ksqlDB クラスターで作業する場合は、このロールを割り当てて構いません。それ以外の場合は、このロールを割り当てないことをお勧めします。
- ClusterAdmin
クラスター(ksqlDB クラスター、Kafka クラスター、または Schema Registry クラスター)をセットアップします。
Kafka クラスター、ブローカー、ネットワーキング、ksqlDB クラスター、Connect クラスターのセットアップと管理、ノードの追加と削除、アップグレードの実行の責任を負います。
ClusterAdmin
は通常、トピックを作成し、それらのトピックのプロパティ(パフォーマンスや容量など)を設定しますが、トピックの読み取りや書き込みはできず、データにもアクセスできません。アプリケーションのモニタリングを行うには、アプリケーションをモニタリングする Operator にこのロールを委任することをお勧めします。通常ClusterAdmin
ユーザーはクラスターデータの内容に関する知識を持っておらず、ResourceOwner
ロールを割り当てられたユーザーにこれらのリソースの所有権に関する責任を委任します。たとえば、トピックを作成した後、ClusterAdmin
は、トピックデータに精通している特定のユーザーに所有権を設定できます。- UserAdmin
MDS によって管理されるすべてのクラスター内のユーザーとグループについて、ロールバインディングを管理します。
クラスター内のユーザーとグループを管理します。これには、ロールに対するユーザーとグループのマッピングも含まれます。他のリソースにはアクセスできません。通常、
UserAdmin
ロールを持つユーザーは、 リソース へのアクセスのセットアップを任されます。このロールを付与されるユーザーは、自分自身や他のユーザーにロールを付与できるため、確実に信頼できる人物である必要があります。監査ログを使用すると、UserAdmin
のアクションをモニタリングできます。- SecurityAdmin
プラットフォーム全体のセキュリティイニシアティブの管理を可能にします。
セキュリティ関連の機能(暗号化、監査ログの追跡、異常な動作の監視など)をセットアップします。セキュリティ機能の初期セットアップと継続的な管理に必要な、専用のユーザーセットを指定するために使用します。
- AuditAdmin
- MDS クラスターおよびすべての登録済み Kafka クラスターに対してこのロールを割り当てられているユーザーまたはグループは、 Confluent Metadata API を使用して監査ログ構成を管理できます。
- Operator
クラスターの運用管理を行い、必要に応じてアプリケーションを拡張します。
アプリケーションとクラスターの状態をモニタリングします。これには、稼働時間のモニタリングも含まれます。このロールでは、アプリケーションを作成することも、トピックのコンテンツの表示または編集を許可することもできません。ただし、存在するトピックとパーティションを表示することはできます。
- ResourceOwner
重要なリソースの所有権を移行し、これらのリソースに対する認可の管理機能を拡張します。
リソース を所有し、読み取り、書き込み、リスト表示などを行うための、リソースへのフルアクセスが許可されています。ResourceOwner は、リソースへのアクセスを必要とする他のユーザーにアクセス許可を付与できます。パーティションの数など、オーナーが変更できない構成もあります。他のユーザーにリソースへのアクセスを許可するには、そのリソースを所有している必要があります。重要なリソースに関する認可のスケーリングを有効にすることができます。
- DeveloperRead、DeveloperWrite、DeveloperManage
- 開発者が、特に開発環境、テスト環境、およびステージング環境で、開発中のアプリケーションの実装を進め、コンテンツを管理できるようにします。
RBAC ロールのユースケース¶
ここで取り上げるユースケースは、事前に定義された RBAC ロールを使用してセキュリティを管理する、以下の新しいプロジェクトに基づいています。
事前に定義されたロール | 計画 |
---|---|
super.user | Sam には、すべてのプロジェクトリソースと操作へのフルアクセスが許可されています。Sam はプロジェクトで使用するロールの初期セットを作成します。 |
ResourceOwner | Ryan は、プレフィックス finance_ が付いたすべてのトピックを所有します。Ryan は、このリソースにアクセスして使用するためのアクセス許可を他のユーザーに付与できます。このユースケースでは、財務トピックの ResourceOwner です。 |
UserAdmin | Uri は、プロジェクトのユーザーとグループを管理します。 |
Operator | Olivia は、プラットフォームとアプリケーションの運用管理および正常性管理を担当します。 |
ClusterAdmin | Cindy は、Kafka クラスターの中心チームのメンバーです。 |
DeveloperRead、DeveloperWrite、DeveloperManage | David は、アプリケーションの開発と管理を担当します。 |
以下のユースケースでは、事前に定義されたロールの用途を示し、RBAC の事前に定義されたロールを活用する方法の一例について説明しています。
ユースケース | 説明 | ロール |
---|---|---|
super.user がプロジェクトを開始する | 初期構成中に、Sam は構成ファイルを介して super.user のアクセス権限を付与されます。これで Sam は、MDS をホストしている Kafka クラスター内のすべてのリソースにアクセスでき、MDS によって管理されている任意のリソースへのロールバインディングを作成できます。 | super.user |
(JIRA などの企業向けツールを使用して)ユーザーを招待し、Confluent Platform プラットフォームを構築する | Sam は次のように、ユーザーとグループにロールバインディングをセットアップします。
|
UserAdmin、SystemAdmin |
UserAdmin がロールを定義し、割り当てる | Uri が以下のアクションを実行します。
|
UserAdmin、ResourceOwner、ClusterAdmin、Operator |
ClusterAdmin がトピックやその他のリソースを作成する | Cindy がプロジェクトに参加して、Kafka クラスターを管理します。Cindy は次のことを行います。
|
ClusterAdmin |
データガバナンスを実装する |
|
ResourceOwner |
開発者がアプリケーションを作成する | David は、トピック(
|
DeveloperWrite、DeveloperRead、DeveloperManage |
クラスターの正常性をモニタリングして適切なアクションを実行する | Olivia は、クラスター内のリソースの正常性を管理する責任を負い、必要に応じてアクションを実行します。たとえば、コネクターにパフォーマンスの問題がある場合は、インスタンスの数を増やしたり、規模を拡大したりできます。 | Operator |