ロールベースアクセス制御を使用した認可

ロールベースアクセス制御(RBAC)は、組織内のユーザーに割り当てられたロールに基づいてシステムアクセスを制御する方法です。RBAC は、事前定義されたロール とそれらのロールに関連付けられた権限("ロールバインディング" とも呼ばれます)を中心に定義されます。ロールは、リソースにバインドできるアクセス許可のコレクションです。このバインディングにより、そのロールに関連付けられた権限を該当するリソースで実行できます。リソースをロールにバインドする際に、ロールをプリンシパルに付与する必要があります。

RBAC では、特定の Confluent Platform リソースに誰がアクセスでき、そのリソース内でユーザーがどのようなアクションを実行できるかを管理します。RBAC を使用すると、Confluent Platform Metadata Service を活用して、一元的な構成コンテキストから RBAC 実装を構成および管理することにより、Confluent Platform リソース全体のアクセス管理を簡素化できます。

RBAC を実装する前に、組織内のユーザーのセキュリティニーズを評価し、ユーザーが職務を遂行するために必要なリソースに基づいて、要件を満たすロールにユーザーをグループ化する必要があります。この計画タスクの例については、「RBAC ロールのユースケース」を参照してください。ベストプラクティスは、ユーザーを割り当てるロールを、タスクを完了するために必要な最小限のロールに制限することです。

ACL と同様に、RBAC にはプリンシパルが使用されるため、クライアントが使用しているプリンシパルすべてを RBAC ロールに関連付けることができます。RBAC ロールには、Confluent Server Authorizer によって RBAC と ACL の両方とのやり取りが認可されます。Confluent Server Authorizer の詳細については、「Confluent Server Authorizer」を参照してください。RBAC ロールでは DENY ルールがサポートされていません。RBAC を併用した場合も、 従来の ZooKeeper ベースの ACL を作成および使用する方法に違いはありません。ただし、ACL を引き続き使用する場合は、ロールバインディングのように、ACL 情報を MDS に格納する 一元的な ACL に移行することをお勧めします。当面の間、従来の ZooKeeper ベースの ACL も引き続き使用できます。

RBAC の有効化と構成の詳細については、「Metadata Service の構成オプション」および「Metadata Service (MDS) の構成」を参照してください。

RBAC の利点

RBAC により、次のことが可能になります。

  • ユーザーとグループのアクセスを制御するためのきめ細かいアクセス許可を使用して、Confluent Platform 全体( Kafka、ksqlDB、Connect、Schema Registry、Confluent Control Center )のセキュリティアクセスを管理できます。たとえば、RBAC を使用すると、クラスター内で各コネクターのアクセス許可を指定できるため、複数のコネクターをより簡単かつ迅速に稼働させることができます。
  • 認可を広範に管理できます。管理者は、事前定義されたロールの割り当てを一元管理できます。リソースのオーナーでありそのリソースに最も精通しているさまざまな部門や部署に、アクセス権限とアクセス許可を管理する責任を委任することもできます。
  • MDS、Kafka クラスター、Connect、ksqlDB、Schema Registry のクラスター、および Confluent Control Center の単一インスタンスを含む複数のクラスターの認証と認可を一元管理できます。

RBAC の仕組み

事前定義されたロールの割り当てにより、特定の Confluent Platform リソースに誰がアクセスでき、そのリソース内で個々のユーザーがどのようなアクションを実行できるかが決まります。管理者は、さまざまなリソースについて、ユーザーとグループに事前定義されたロールを割り当てます。各ユーザーには、各リソースに対する複数のロールを割り当てることができます。特定の権限を持つユーザー(UserAdminSystemAdmin など)は、ユーザーとグループにロールを割り当ててから、特定のリソースをそれらのユーザーロールにマップします。たとえば、財務部門の ResourceOwner は、プレフィックス finance_ が付いたすべてのトピックへのアクセス権限を部門のメンバーに付与できます。これにより、部門のメンバーが最も精通しているリソースを管理しやすくなります。

ユーザー管理者は LDAP ユーザーとグループを追加できます。これにより、組織で使用されるさまざまな Confluent Platform リソースの認証と認可を一元的に構成する作業を、より迅速かつ簡単に行うことがます。

../../_images/rbac-overview.ja.png

RBAC の概要

With RBAC, the user administrator can map roles to LDAP users and groups that are scoped to specific resources (role binding). After a role binding is set using the Confluent CLI confluent iam rolebinding create command, users can't go to an API or Confluent Control Center to bypass and get access to resources. Binding roles to groups enables client administrators to avoid having to grant explicit access to each user across every component. For details about viewing role bindings, refer to Confluent CLI confluent iam rolebinding list command. Note that role binding does not support wildcard matching in principal names. For details, refer to ワイルドカードプリンシパル.

注釈

ロールバインディングのセットアップ(confluent iam rolebinding create)についてトラブルシューティングが必要な場合は、監査ログをオンザフライで表示して、特定のプリンシパル、リソース、または操作の認可イベントを確認すると役立つ場合があります。詳細については、「監査ログのオンザフライ表示」を参照してください。

Confluent Platform cluster registry を使用すると、クラスター管理者は Kafka クラスターを Metadata Service(MDS)に一元的に登録し、さらに簡単に RBAC のロールバインディングに関する操作を行うことができます。詳細については、「クラスターレジストリ」を参照してください。

Confluent Platform Metadata Service

MDS は、RBAC を実装するための主要なメカニズムであり、単一の一元的な構成コンテキストを提供します。これにより、クラスター用のセットアップ後、各リソースに対するロールを個別に定義して割り当てるという複雑で時間のかかるタスクから管理者を解放できます。Confluent Platform MDS は、さまざまなリソース(トピック、コネクター、スキーマなど)にわたって Kafka クラスター構成をバインドおよび適用します。Metadata Service (MDS) は、すべての認可および認証データを一元的に管理する機能です。MDS クラスター内の各 Kafka ブローカーは、MDS で構成する必要があります。

MDS により、role-based access control (RBAC) 実装の使いやすさと利便性が向上します。たとえば、バインディングを使用しない同じアクセス許可モデルを使用して、他のタイプのセキュリティを提供できるように拡張することもできます。

Kafka ブローカーで実行される MDS は LDAP とも統合され、権限借用に必要な認証と更新可能なベアラートークンを提供します。MDS は、ロールバインディングに関する記録も管理します。RBAC との LDAP 統合の構成については、「LDAP Authorizer の構成」および「LDAP 認証の構成」を参照してください。MDS の構成の詳細については、「Metadata Service (MDS) の構成」を参照してください。

RBAC と ACL

RBAC は認可適用レイヤーとして ACL に追加して使用できますが、その場合も ACL の作成方法または管理方法は変わりません。アクセス制御に RBAC と ACL のどちらを使用するかを検討するときは、使いやすさと広範な管理性という点で、RBAC をデフォルトとして使用することをお勧めします。ただし、よりきめ細かいアクセス制御が必要な場合や、明示的にアクセスを拒否する必要がある場合は、ACL の方が適している可能性があります。たとえば、RBAC を使用してユーザーのグループにアクセスを許可し、ACL を使用してそのグループの特定のメンバーに対してアクセスを拒否することができます。

RBAC は、ACL を使用する場合の以下のような認可の問題に対処するための認可メカニズムを追加します。

  • RBAC を使用していない場合、ACL ではコネクターにアクセス権限を付与できません。RBAC を使用している場合は、各コネクターに、リソースに対するアクセス権限を識別する独自のプリンシパルがあります。ユーザーは、明示的にアクセス許可が付与されているコネクターにのみアクセスできます。コネクターのアクセス制御が必要な場合は、RBAC が不可欠です。

  • RBAC を使用すると、Confluent Control Center ユーザーはリソースへのきめ細かいアクセスを利用できます。RBAC の導入前は、Confluent Control Center にアクセスできるすべてのユーザーに、トピックおよびリソースへの完全アクセスまたは読み取り専用アクセスが許可されていました。Confluent Control Center でのきめ細かいアクセス制御が必要な場合は、RBAC の使用をお勧めします。

  • RBAC では、Confluent Platform 全体にわたるユーザーアクセスに関して、一貫した認証および認可のメカニズムを実現できます。これは、ACL のみを使用する場合には不可能です。

  • RBAC の登場前は、ACL の作成と管理は困難な場合があり、何千ものリソースとユーザーを扱う組織では ACL のセットアップに長い時間がかかる可能性がありました。RBAC の登場後は、さまざまなリソースへの責任の委任を ResourceOwner ロールで管理できるようになりました。

    たとえば、1000 個のトピックへのユーザーアクセスの管理を担当しているとします。RBAC を使用すると、特定の部署が所有するトピックを管理できるように、他のユーザーに ResourceOwner を付与することができます。これらのユーザーは、チーム内の他のメンバーに代わってアクセスを管理することもできます。このシナリオで ACL を使用する場合は、すべてのトピックへのアクセスを一元管理する必要があり、そのタスクには多くの時間とリソースが必要になります。

RBAC 認証オプション

RBAC の実装前に使用されている認証オプションで追加の構成が必要となる場合や、まったく別の認証方式を使用することが必要となる場合があります。

重要

RBAC を使用する場合、REST エンドポイントを持つ Confluent Platform コンポーネント(Schema Registry や Confluent Control Center など)では、mTLS 認証から派生したプリンシパルの使用はサポートされません。したがって、RBAC の構成前に Confluent Platform 全体で SSL 証明書認証に依存していた場合は、RBAC の使用時に他のコンポーネントや REST API エンドポイントに対して認証を行うために、HTTP 基本認証の認証情報(LDAP ユーザーなど)も提供する必要があります。

HTTP 基本認証は、他の Confluent Platform コンポーネントにログイン認証情報を提示します。コンポーネントでは、それらの認証情報を使用して、MDS によってユーザーの OAuth トークンを取得します(MDS は、LDAP に照らして認証情報を検証します)。その後、コンポーネントは OAuth トークンを使用して、MDS への認可リクエストを作成します。HTTP 基本認証 のベアラートークンを指定する必要があります。より具体的には、basic.auth.user.infobasic.auth.credentials.source を指定する必要があります。

Confluent Platform コンポーネント(Confluent Control Center、ksqlDB、REST Proxy など)を RBAC 向けに構成するときは、MDS および Kafka クラスターとの認証に OAuth を使用します。他の Confluent Platform コンポーネントとの認証には、HTTP 基本認証 を使用します。

Schema Registry および Connect で RBAC を使用するときは、Confluent Platform でサポートされる任意の 認証方式 を使用して、Kafka クラスターや MDS と通信できます。他の Confluent Platform コンポーネントとの認証には、HTTP 基本認証 を使用します。

Kafka クライアントで RBAC を使用するときは、Confluent Platform でサポートされる 認証方式 のうち、"OAUTHBEARER 以外" の任意の方式を使用できます。詳細については、「Kafka クライアントの構成」を参照してください。

RBAC の使用時に使用可能な認証方式を示す図

RBAC 認証オプション

用語

RBAC では以下の用語を使用します。

アクセス制御
アクセスとは、個々のユーザーまたはアプリケーションが、リソース(トピックなど)の表示、作成、変更など特定のタスクを実行する能力です。アクセス制御により、Confluent Platform サービスおよびリソースへのセキュアなアクセスが可能になります。
プリンシパル
特定のリソースに対して特定のアクションを実行するためのアクセス許可をリクエストするユーザーまたはソフトウェアの ID。認証済みのプリンシパルと認証されていないプリンシパル(ANONYMOUS)があります。
ユーザープリンシパル
特定のユーザーまたはソフトウェアに関連付けられた単一の ID。
グループプリンシパル
ユーザープリンシパルまたは他のグループプリンシパル、あるいはその両方のリストをグループ化する共有 ID。
ロール
特定の操作の実行をプリンシパルに許可するための一連のアクセス許可。
リソース
リソースとは、Apache Kafka® のトピック、コンシューマーグループ、トランザクション ID、クラスター、Schema Registry、ksqlDB や、その他の Confluent Platform コンポーネントのことです。
ロールバインディング
ロールでの定義に従い、リソースまたはリソースのセットに対する操作をプリンシパルに許可するための、プリンシパル/ロール/リソースの組み合わせ。
ロールベースアクセス制御(RBAC)
RBAC を使用すると、アクセス許可がロールに関連付けられ、ユーザーまたはグループが適切なロールに割り当てられます。ロールは、企業内の職務能力、権限、義務に従って定義されます。ユーザーとグループは、あるロールから別のロールに簡単に割り当て直すことができます。ロールに割り当てられるアクセス許可は、ロールのユーザーメンバーシップと比較して、変更が生じる速度が比較的遅い傾向があります。

RBAC の制限

RBAC 構成を最適に機能させるには、以下の制限に従うことをお勧めします。

リソース 制限
ロールバインディング 1000
ロールバインディングを追加、削除、または検索するための API 呼び出しによる 1 秒あたりのリクエスト数(RPS) 15
一元的な ACL クラスターごとに最大 1000

重要

グループロールバインディングに指定するユーザー ID では大文字と小文字が区別され、AD レコードでの指定と一致する必要があります。スーパーユーザーとしてログインするときは、ログイン ID の大文字と小文字も区別され、ロールバインディング内のユーザー ID の指定と一致する必要があることにも注意してください。

RBAC のエラーコード

RBAC では、以下のユーザーアクセス HTTP エラーコードが使用されています。

注釈

ユーザーの認証情報が正しくても、ユーザーに正しいアクセス許可がない場合は、404 エラーではなく 403 エラーが発生することがあります。そのような場合は、特定のリソースに関する詳細が公開されないように、エラーコード 403 が返されます。

401
認証情報がないか不十分であるため、ユーザーのログインに失敗しました(ユーザーに十分なアクセス許可がありません)。
403
正しいユーザー認証情報が指定された可能性がありますが、特定のリソース(Schema Registry や Connect など)に対して必要なアクセス許可がユーザーにないため、ログインに失敗しました。
404
見つかりません: ユーザーには正しい認証情報とリソースへのアクセス許可がありますが(ユーザーに ResourceOwner ロールが付与されているなど)、リソース(Connect など)が存在しません。
502
MDS に到達できません。セキュリティ管理者にお問い合わせください。

Schema Registry には、RBAC のコンテキスト以外にも多くの詳細なエラーコードがあります。ここで説明されていない Schema Registry HTTP エラー(40401 など)の説明については、「Schema Registry API リファレンス」を参照してください。

RBAC の実装チェックリスト

このセクションでは、RBAC の実装を計画するために役立つチェックリストをご紹介します。

注釈

Ansible には、RBAC および MDS の構成とデプロイを簡単に行う方法が用意されています。詳細については、Ansible の RBAC 設定 を参照してください。

RBAC をセットアップするには、次の手順に従います。

Confluent Platform のインストールconfluent-server 商用コンポーネントを含む)。詳細については、「Confluent Server への移行」を参照してください。

☐ セキュリティチームと協力し、組織内のユーザーのニーズを評価したうえで、職務を遂行するために必要なリソースに基づき、ユーザーとグループに割り当てるロールを特定します。

一般的なユースケースとそれぞれに必要なロールの説明については、「RBAC ロールのユースケース」を参照してください。

RBAC をブートストラップするには、MDS をホストするクラスターで、Kafka ブローカーの server.properties ファイル内にある ACL レベルの super.user を特定する必要があります。この super.user は、SystemAdmin ロールを別のユーザーに割り当てることができます。そのユーザーは、必要なクラスターを作成し、ユーザーとグループに必要なロールバインディングのスコープを設定できます。ブートストラップ用 super.user として使用するユーザーを必ず特定してください。詳細については、「ロールベースアクセス制御の事前定義されたロール」を参照してください。

Metadata Service(MDS)を構成 します。

MDS は RBAC のコア機能を実装しており、 LDAP と通信 してユーザーとグループの情報を取得し、ユーザーを認証します。MDS を構成した後、他の Confluent Platform コンポーネントのロールバインディングと構成に進むことができます。

MDS 用の LDAP 構成については、「LDAP ID プロバイダーの構成」を参照してください。

☐ ユーザーとグループに割り当てる必要のあるロールを決定したら、ユーザーが職務を遂行するうえで必要となるリソース(Schema Registry、ksqlDB、Connect、Confluent Control Center など)にアクセスするための適切な ロールバインディング を作成します。

☐ Confirm the user and group roles you defined using the confluent iam rolebinding list command.

☐ 認証と認可のために MDS と通信できるように Confluent Platform コンポーネントを構成します。詳細については、以下を参照してください。

デモ

role-based access control (RBAC) の実際の例については、「Confluent Platform のデモ」を参照してください。このデモと付属のチュートリアルでは、Apache Kafka® イベントストリーミングアプリケーションのデプロイ方法を紹介しています。デモのすべてのコンポーネントでは、RBAC を含めてエンドツーエンドでセキュリティが有効になっています。