ロールベースアクセス制御の事前定義されたロール

ロールは、ユーザーが実行できるタスクを定義する、アクセス許可の集合体です。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 リソースレベル × × × × ×
注意事項:
  1. AuditAdmin ロールでは、監査ログ構成を作成および管理するための十分なアクセスが許可されます。
  2. 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 は次のように、ユーザーとグループにロールバインディングをセットアップします。

  • Uri: ユーザー/グループを管理するための UserAdmin ロールが付与されます。
  • 必要に応じて、Sam はクラスターに対する SystemAdmin ロールを他のユーザーに付与できます(どうしても必要な場合のみ)。
UserAdmin、SystemAdmin
UserAdmin がロールを定義し、割り当てる

Uri が以下のアクションを実行します。

  • 必要に応じて、Uri は企業 LDAP に新しいグループ(Kafka 開発者グループなど)を作成します。これにより、複数のユーザーのロールバインディングを同時に管理しやすくなります。
  • プレフィックス finance_ が使用されているトピックに対する ResourceOwner ロールを Ryan に付与します。
  • 運用を管理できるように、Connect クラスターに対する Operator ロールを Olivia に付与します。
  • ClusterAdmin ロールを Cindy に付与します。これで Cindy はクラスターを管理できるようになります。
UserAdmin、ResourceOwner、ClusterAdmin、Operator
ClusterAdmin がトピックやその他のリソースを作成する

Cindy がプロジェクトに参加して、Kafka クラスターを管理します。Cindy は次のことを行います。

  • ブローカーを管理し、必要に応じて構成を更新します。
  • 財務開発チーム用にトピックを作成するリクエストを受け取ります。
    • Cindy はプレフィックス finance_ が付いたトピックを作成します。
    • Cindy がこれらのトピックの読み取り/書き込みを行うことはできません。
ClusterAdmin
データガバナンスを実装する
  • Ryan は、プレフィックス finance_ が付いたすべてのトピックに対する ResourceOwner 権限を持っているため、これらすべてのトピックを表示できます。
  • Ryan は、プレフィックス finance_ が付いたすべてのトピックに対する適切なアクセス権限を付与します。
  • トピックやその他の重要なリソースへのアクセスリクエストが発生すると、既存の企業ワークフローを通じて、Ryan に通知されます。Ryan はこれらのアクセスを許可または拒否できます。
ResourceOwner
開発者がアプリケーションを作成する

David は、トピック(finance_report)に対して生成を行う新しいアプリケーションを作成する必要があります。

  • David が(Uri によるユーザー/グループマッピングを介して)開発者としてまだ追加されていない場合、David は Ryan にアクセス権限をリクエストする必要があります。
  • Ryan(ResourceOwner)は、トピック finance_report に対する DeveloperWrite ロールを David に付与します。
  • Ryan(ResourceOwner)は、David のアプリケーションで実行する必要のある操作の種類に応じて、David に DeveloperRead または DeveloperManage ロールを付与することもできます。
DeveloperWrite、DeveloperRead、DeveloperManage
クラスターの正常性をモニタリングして適切なアクションを実行する Olivia は、クラスター内のリソースの正常性を管理する責任を負い、必要に応じてアクションを実行します。たとえば、コネクターにパフォーマンスの問題がある場合は、インスタンスの数を増やしたり、規模を拡大したりできます。 Operator