Schema Registry のロールベースアクセス制御の構成

Looking for Schema Management Confluent Cloud docs? You are currently viewing Confluent Platform documentation. If you are looking for Confluent Cloud docs, check out Schema Management on Confluent Cloud.

Confluent Schema Registry では、ロールベースアクセス制御を使用した認可 (RBAC)がサポートされます。

ユーザーには、特定のトピックと(Schema Registry サブジェクト に含まれている)その関連スキーマに対する管理、読み取り、書き込みのアクセス権が RBAC ロール に基づいて付与されます。特定のリソースおよび Schema Registry でサポートされている 操作 が、ユーザーアクセスの対象範囲となります。

RBAC が有効になっていると、Schema Registry で受信リクエストを認証し、ロールバインディングに基づいてそれらを認可できます。これにより、管理ユーザーだけがスキーマの進化を管理できるよう制限するとともに、認可を受けたサブジェクトのサブセットに対するさまざまな種類のアクセス権をユーザーやアプリケーションに付与することができます(関連するサブジェクトに対する書き込みのアクセス権をプロデューサーに、読み取りのアクセス権をコンシューマーに付与するなど)。

概要

Schema Registry のサブジェクトとトピックに対するユーザーのアクセスは、RBAC があることで容易に、かつ効率よくセットアップし、管理することができます。

RBAC 以前のスキーマ管理

RBAC がなければ、管理者がひとつひとつのサブジェクトを指定するか、 * (すべて)を使用して、ユーザーが必要とする個々の操作(SUBJECT_READ、SUBJECT_COMPATIBILITY_READ など)を指定する必要があります。スキーマの読み取りを必要とする開発者が 100 人いれば、アクセス権も 100 回セットアップしなければなりません。

../../_images/sr-pre-rbac.ja.png

RBAC 以前の Schema Registry

RBAC を使用したスキーマ管理

RBAC を利用できる環境は、次のユースケースに対応します。

  • Jack は、Samantha に DeveloperRead ロールを割り当てることで、制限されたアクセス権を Samantha に与えるとともに、一連のサブジェクトをプレフィックスで指定することができます。
  • Samantha には、サブジェクトごとに異なるロールを割り当てることができます。"transactions-value" と "orders-value" に対しては DeveloperRead を割り当てる一方で、"customers-value" に対しては DeveloperWrite ロールを割り当てることができます。
  • Jack は、社内の開発者 100 人にロールを割り当てる必要がある場合、開発者用のグループを作成し、Schema Registry 内のスキーマに対する読み取り専用アクセス権をそのグループに付与することができます。
../../_images/sr-rbac.ja.png

RBAC を使用した Schema Registry

Self-Balancing Clusters のしくみ

Schema Registry の HTTPS エンドポイントに対してクライアントが通信を行う際、Schema Registry は、クライアントの認証情報を Metadata Service(MDS)に渡して認証を行います。MDS は、Confluent Server における Kafka ブローカーの REST レイヤーです。LDAP と連携し、Schema Registry やその他の Confluent Platform サービス(Connect、Confluent Control Center、ksqlDB など)の代わりに、エンドユーザーの認証を行います。「Confluent Platform のデモ(cp-demo)」でも触れているように、クライアントには、あらかじめ定義された LDAP エントリが必要です。

クライアントが認証されたら、認可されたエンティティ以外、許可されているリソースにアクセスできないようにする必要があります。これは ACL と RBAC のどちらか、またはその両方を使用して行うことができます。ACL と RBAC は一緒に使用することも、個別に使用することもできます。推奨されるソリューションは RBAC です。RBAC の方が粒度の細かい認可の運用が可能であり、Confluent Platform 全体のアクセス管理手法とも一貫性があります。

以下の図に示したのは、Schema Registry に接続する Kafka クライアントに対して認証と認可を行う一連のワークフローです。

../../_images/sr-rbac-rest-api-request.ja.png

セットアップの概要

スキーマに対する role-based access control (RBAC) を有効にするには、RBAC を実行する Metadata Service(MDS) への接続情報を含んだ schema-registry.properties ファイルを構成し、Confluent CLI を使用して、ユーザーとアプリケーションに、サブジェクトやその他のリソースに対するアクセス権を ロール に基づいて付与する必要があります。

通常、RBAC に必要なアカウントのアクセス権と MDS 情報は、セキュリティ管理者にリクエストします。

セキュリティ管理者ロールに属するユーザーとして完全なローカルセットアップを行う場合、まず MDS を使用して RBAC をセットアップした後、Confluent CLI を使用して、Schema Registry に対する service principal を作成することになるでしょう。

その後、ResourceOwnerDeveloperReadDeveloperWriteDeveloperManage など、さまざまなロールを持ったプリンシパルユーザーアカウントを作成し、サブジェクト(Kafka のトピックに関連付けられたスキーマ)やその他のリソースにそれらのロールをバインドすることができます。

操作に対するロールのマッピングとサブジェクトベースの認可

Schema Registry の構成が済んで RBAC 対応の環境で実行されていれば、ユーザーは、リソースの操作に関して自分に割り当てられた認可(ロールrolebinding)に基づいて、サブジェクトのスキーマを読み取ったり書き込んだりすることができます。

RBAC は、操作 一覧に記載されている、Schema Registry の操作をすべてサポートします。これらの操作の詳細については、「スキーマレジストリ API」を参照してください。

ロール名 Read Write 削除 互換性読み取り 互換性書き込み
SystemAdmin
UserAdmin × × × × ×
ClusterAdmin
Operator × × × × ×
SecurityAdmin × × × × ×
ResourceOwner ○(スコープに応じて) ○(スコープに応じて) ○(スコープに応じて) ○(スコープに応じて) ○(スコープに応じて)
DeveloperRead ○(スコープに応じて) × × ○(スコープに応じて) ×
DeveloperWrite × ○(スコープに応じて) × × ×
DeveloperManage × × ×

ちなみに

  • Schema Registry には、独自のクラスターが存在します。
  • 複数のスキーマレジストリを利用することができます。
  • 1 つの Schema Registry クラスターを複数の Kafka クラスターに接続することができます。
  • ロールに関して "グローバルな互換性" という概念はありません。グローバルな互換性を管理するためのアクセス許可をユーザーに付与するには、__GLOBAL という名前のサブジェクトリソースに対する DeveloperManage ロールをユーザーに割り当ててください。
  • Confluent Platform 5.4.x 以降では、developerRead ロールと developerWrite ロールのユーザーが Confluent Control Center から Schema Registry 上の スキーマを閲覧したり操作したりする 必要がある場合、developerManage ロールも必要となります。(5.4.x 未満では、developerRead ロールと developerWrite ロールがあれば、Control Center から Schema Registry に対する操作を行うことが可能でした。)

ClusterAdmin のユースケースの例

ClusterAdmin である Jack は、自身が所属する組織の Schema Registry クラスターをセットアップしたいと考えています。

手順 1. クラスター管理者である Jack が、RBAC セキュリティ管理者に連絡します。その際、次の情報を伝えます。

  • 使用する Kafka クラスター(選択肢が複数ある場合)
  • Schema Registry クラスター ID(schema-registry-a など)
  • Jack のプリンシパル名
  • Schema Registry に必要なリソース(スキーマトピック、スキーマトピックグループなど)

手順 2. UserAdmin が、Schema Registry クラスターを表す service principal を作成し、次の作業を行います。

  • その service principal に、内部スキーマトピックへのアクセス許可と、Schema Registry クラスターが動作するうえで必要なその他のロールを付与します。
  • その service principal の認証情報を Jack に与えます。
  • Schema Registry クラスターの ClusterAdmin ロールを Jack に付与します。
  • リクエストの認証に使用できるパブリックキーを Jack に支給します。

手順 3. Jack は、支給されたパブリックキー、指定されたグループ ID("schema-registry-a" など)、UserAdmin から提供された service principal を使用するように Schema Registry クラスターを構成したうえで、クラスターを立ち上げます。

ユーザーエクスペリエンスの例

開発者である Samantha は、自身のアプリケーションで扱う必要のあるスキーマを把握するために、"transactions-value" と "orders-value" の 2 つのサブジェクトに対する READ アクセス権を必要としています。

手順 1. 開発者である Samantha がユーザー管理者に連絡します。その際、次の情報を伝えます。

  • 一連のサブジェクト("transactions-value"、"orders-value" など)
  • Schema Registry クラスター ID("schema-registry-a" など)

手順 2. それらのサブジェクトへのアクセス権を UserAdmin が Samantha に付与します。

手順 3. Samantha が GET /subjects を実行すると、"transactions-value" と "orders-value" だけが表示されます。

手順 4. これらのサブジェクトに対する、不注意による POSTDELETE 操作が防止されます。

クイックスタート

このクイックスタートでは、トピックやサブジェクト(スキーマ)に対するユーザーとアプリケーションの認可をロールベースアクセス制御で管理するように Schema Registry を構成する方法について説明します。次の方法について取り上げています。

  • 起動後、RBAC 対応の Apache Kafka® クラスターに接続するように Schema Registry を構成します(schema-registry.properties を編集し、Confluent CLI を使用してロールを作成 します)。
  • Confluent CLI を使用して、Schema Registry の service principal に SecurityAdmin ロールを付与します。
  • Confluent CLI を使用して、内部トピックおよび(Schema Registry クラスター全体の調整に使用される)グループの ResourceOwner ロールを Schema Registry の service principal に付与します。
  • Confluent CLI を使用して、トピック(および Schema Registry 内の関連するサブジェクト)へのアクセス権をユーザーに付与します。

紹介している例では、共有 RBAC と MDS 構成、および Schema Registry のローカルインストールが想定されています。実際の本稼働環境は異なる場合があります(Confluent Cloud、リモート Schema Registry など)。

テストの場合のように、ローカルの Kafka、ZooKeeper、ブートストラップサーバーを使用した場合、それらも RBAC での認可が必要となるため、必要な前提条件のセットアップと認証情報も増えます。

参考

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

始める前に

Confluent Platform または Schema Registry を初めて利用する方は、まず、次のチュートリアルに取り組んで、Confluent Platform 全体のプラットフォームや Schema Registry、ロールベースアクセス制御の基本的な知識を身に付けることをお勧めします。

手順の概要

../../_images/sr-rbac-setup.ja.png

Schema Registry RBAC クイックスタートの概要

前提条件

Schema Registry をはじめとするリソースを RBAC 環境で実行するためには、Schema Registry の service principal (リソース用のユーザーアカウント)、認証情報、RBAC を実行する Metadata Service (MDS) の場所が必要です。これによって Confluent CLI から、RBAC 対応の Kafka クラスターと通信を行うように Schema Registry のプロパティを構成し、各種のアクセス権を Schema Registry に付与することができます。

作業を始めるにあたっての具体的な要件は次のとおりです。

  • RBAC に対応した Confluent Platform 環境と Schema Registry
  • RBAC を実行する Metadata Service (MDS) の場所。これは、Metadata Service (MDS) の URL(ローカルの MDS をテストしている場合はファイルパス)になります。
  • 組織用のプリンシパルの作成と変更を行うための認可。
  • トークンベースの認可を使用してリクエストを検証するためのパブリックキーファイル
  • Schema Registry のサービス(ユーザー)アカウント

ほとんどの場合、この情報はセキュリティ管理者から入手することになります。

Confluent Platform および Confluent CLI のインストール

  1. ローカルに Confluent Platform をダウンロードしてインストール します(まだ済んでいない場合)。
  2. Confluent CLI をインストールします。

RBAC サービスと通信を行うための Schema Registry の構成

次の一連の例では、RBAC を実行するリモートの Metadata Service (MDS) にローカルの Schema Registry を接続する方法を紹介しています。リモートの Metadata Service (MDS) の URL、場所、Kafka クラスター ID は、schema.registry.properties ファイルの構成に反映されます。また、スキーマレジストリのプリンシパルユーザーについては既に前提条件で触れましたが、その事前構成済みのプリンシパルユーザー("service principal")には、セキュリティ管理者から支給された認証情報が使用されているものとします。

ちなみに

  • 例では、複数行から成るプロパティの値を示すために、キャリッジリターンの前にバックスラッシュ(\)を使用しています。これらの改行とバックスラッシュを実際のプロパティファイルで使用すると、エラーが発生することがあります。その場合は、プロパティの値が改行で複数の行に分割されないよう、バックスラッシュを削除して行を結合してください。
  • 参照するサーバーが複数ある場合は、セミコロンで区切って指定します(metadataServerUrlsconfluent.metadata.bootstrap.server.urls の値など)。

以下の設定は、<path-to-confluent>/etc/schema-registry/schema-registry.properties で定義します。

  1. RBAC Kafka クラスターと通信するための Schema Registry の認可を構成します。

    usernamepassword は、Schema Registry の service principal に使用する RBAC の認証情報です。また、metadataServerUrls は RBAC Kafka クラスターの場所です(ec2 サーバーの URL など)。

    # Authorize Schema Registry to talk to Kafka (security protocol may also be SASL_SSL if using SSL)
    kafkastore.security.protocol=SASL_PLAINTEXT
    kafkastore.sasl.mechanism=OAUTHBEARER
    kafkastore.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
    kafkastore.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
    username="<username>" \
    password="<password>" \
    metadataServerUrls="<http/s>://<metadata_server_url>:<port>";
    
  2. Schema Registry リソースに使用するベアラー/基本認証と RBAC の認可を構成します。

    次の設定はそのまま使用できます。JETTY_AUTH は、推奨される認証メカニズムです。

    # These properties install the Schema Registry security plugin, and configure it to use |rbac| for
    # authorization and OAuth for authentication
    schema.registry.resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension
    confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.rbac.RbacAuthorizer
    rest.servlet.initializor.classes=io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler
    confluent.schema.registry.auth.mechanism=JETTY_AUTH
    

    ちなみに

  3. Metadata Service (MDS) を実行する Kafka クラスターとの通信方法およびパブリックキーを使用してリクエストを認証する方法を Schema Registry に伝えます。

    • 環境によっては、confluent.metadata.bootstrap.server.urlsmetadataServerUrls が同じ値になることがあります。
    • 前提条件でも触れたように、この手順には、トークンベースの認可を使用してリクエストを検証するためのパブリックキーファイルが必要となります。
    # The location of the metadata service
    confluent.metadata.bootstrap.server.urls=<http/s>://<metadata_server_url>:<port>
    
    # Credentials to use with the MDS, these should usually match those used for talking to Kafka
    confluent.metadata.basic.auth.user.info=<username>:<password>
    confluent.metadata.http.auth.credentials.provider=BASIC
    
    # The path to public keys that should be used to verify json web tokens during authentication
    public.key.path=<public_key_file_path.pem>
    

    MDS と通信するクライアントで利用できる追加の構成については、Confluent Platform のセキュリティに関するドキュメントの「REST クライアントの構成」も参照してください。

  4. 使用する kafkastore.bootstrap.server を指定します。

    デフォルトはローカルサーバーで、この行はコメントアウトされています。これを変更しなかった場合またはコメントを解除した場合は、デフォルトが使用されます。

    #kafkastore.bootstrap.servers=PLAINTEXT://localhost:9092
    

    この行のコメントを解除して、使用するブートストラップサーバーのアドレスを設定してください。MDS サーバーの URL とは異なる場合があります。Kafka のブートストラップサーバーに使用される標準ポートは 9092 です。

    kafkastore.bootstrap.servers=<rbac_kafka_bootstrap_server>:9092
    
  5. (省略可能、従来の設定) Schema Registry セキュリティプラグイン を ZooKeeper に接続するために使用する kafkastore.connection.url を指定します。

    デフォルトはローカルの ZooKeeper で、この行はコメントアウトされています。これを変更しなかった場合またはコメントを解除した場合は、デフォルトが使用されます。

    #kafkastore.connection.url=localhost:2181
    

    この行のコメントを解除して、使用する ZooKeeper サーバーのアドレスを設定してください。ZooKeeper サーバーに使用される標準ポートは 2181 です。

    注釈

    kafkastore.connection.url は非推奨となっています。この設定は、以前のバージョン(5.4.x 以前)で Schema Registry セキュリティプラグインがインストールされ、ACL を使用するように構成されている場合に必要でした。Confluent Platform 5.5.0 以降では Schema Registry ACL オーソライザー が使用されるため、この設定は不要となっています。ACL オーソライザーがない場合は、付属しているバージョンの Confluent Platform にアップグレードしてください。Kafka のリーダー選出にアップグレードするには、「ZooKeeper のプライマリ選出から Kafka のプライマリ選出への移行」を参照してください。

  6. (省略可)デフォルト(schema-registry)とは異なるカスタム schema.registry.group.id (Schema Registry クラスター ID として使用されます)を指定します。

    この例では、schema.registry.group.id を "schema-registry-cool-cluster" に設定しています。

    # Schema Registry group id, which is the cluster id
    # The default for |sr| cluster ID is **schema-registry**
    schema.registry.group.id=schema-registry-cool-cluster
    

    ちなみに

    Schema Registry クラスター ID は、schema-registry-group-id (デフォルトでは schema-registry)と同じです。Confluent CLI の rolebinding コマンドでターゲットリソースを指定する際に使用されます。複数のレジストリ内でロールやユーザーが上書きされてしまうのを避けるために、カスタムクラスター ID を指定して、組織内の特定の Schema Registry を他から区別しなければならない場合があります。

  7. (省略可) Schema Registry のデフォルトのトピックにカスタム名を指定します(デフォルトは _schemas)。

    この例では、schema.registry.group.id_jax-schemas-topic に設定しています。

    # The name of the topic to store schemas in
    # The default schemas topic is **_schemas**
    kafkastore.topic=_jax-schemas-topic
    

    ちなみに

    • Schema Registry 自体は、内部トピックを使用してスキーマを保持します。このトピックのデフォルトの名前は _schemas です。スキーマの内部トピックにカスタム名を指定して組織内の他のトピックから区別し、データの上書きを防止しなければならない場合があります。
    • 名前のアンダースコアは必須ではありません。内部トピックであることを示すために慣例的に使用されています。
  8. (省略可)認証を経ずに行われたリクエストへの匿名アクセスを有効にします。

    認証を経ずに行われたすべてのリクエストには、User:ANONYMOUS というプリンシパルが自動的に付与されます。

    # This enables anonymous access with a principal of User:ANONYMOUS
    confluent.schema.registry.anonymous.principal=true
    authentication.skip.paths=/*
    

    サブジェクトを一覧表示するための curl コマンド(「Schema Registry の起動とテスト」を参照)を実行する際に、認可されていないことを示す以下のエラーが発生した場合、認証情報のトラブルシューティングを行う間は、匿名リクエストを有効にすることで、認証を一時的にバイパスすることができます。

    curl localhost:8081/subjects
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
    <title>Error 401 Unauthorized</title>
    </head>
    <body><h2>HTTP ERROR 401</h2>
    <p>Problem accessing /subjects. Reason:
    <pre>    Unauthorized</pre></p><hr><a href="https://eclipse.org/jetty">Powered by Jetty:// 9.4.18.v20190429</a><hr/>
    
    </body>
    </html>
    

    ちなみに

    • 上の curl コマンドは、User:ANONYMOUS の ACL または rolebindings を構成することで正常に実行することができます。
    • REST リクエストで有効な資格情報を提示するという要件はバイパスされますが、その後リクエストに対して実施される認可、つまりその操作を実行するための適切なロールまたは ACL がユーザー(認証情報が提示されなかった場合は User:ANONYMOUS)にあることを確認するための処理はバイパスされません。

使用する MDS サーバーの Kafka クラスター ID の取得

この情報は、Confluent CLI の rolebinding コマンドで、使用する Kafka クラスターを指定する際に必要となります。

  • ローカルホストの Kafka クラスター ID を取得する: bin/zookeeper-shell localhost:2181 get /cluster/id
  • リモートホストの Kafka クラスター ID を取得する: zookeeper-shell <host>:<port> get /cluster/id

たとえば、現在このコマンドの出力には、Kafka クラスター ID(my-kafka-cluster-ID)が表示されます。

zookeeper-shell <metadata_server_url>:2181 get /cluster/id

出力は以下のようになります。

Connecting to <metadata_server_url>:2181

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
{"version":"1","id":"my-kafka-cluster-ID"}
...

Schema Registry の service principal に対するロールの付与

以下の手順では、Confluent CLI を使用して MDS にログオンし、Schema Registry の service principal を作成します。各ロールのセットアップ後、Confluent CLI を使用して Schema Registry のユーザーを管理できます。この例では、コマンドに、ローカル Schema Registry のプロパティファイルでセットアップした MDS サーバーの認証情報、URL、プロパティの値を使用するものとします(必要に応じて、ロールバインディングには 登録済みのクラスター名 を使用できます)。

  1. MDS にログオンします。

    confluent login --url <http/s>://<metadata_server_url>:<port>
    
  2. Schema Registry クラスターの SecurityAdmin ロールをユーザーに付与します。

    confluent iam rolebinding create \
    --role SecurityAdmin \
    --principal User:<service-account-id> \
    --kafka-cluster-id <kafka-cluster-id> \
    --schema-registry-cluster-id <schema-registry-group-id>
    
  3. 作成したロールを confluent iam rolebinding list <flags> コマンドで表示します。

    confluent iam rolebinding list \
    --principal User:<service-account-id> \
    --kafka-cluster-id <kafka-cluster-id> \
    --schema-registry-cluster-id <schema-registry-group-id>
    

    たとえば、Kafka クラスター my-kafka-cluster-ID を通じて MDS に接続し、"schema-registry-cool-cluster" の SecurityAdmin ロールが付与されたユーザー "jack-sr" について、このコマンドを実行した場合、次の結果が返されます。

    confluent iam rolebinding list \
    --principal User:jack-sr \
    --kafka-cluster-id my-kafka-cluster-ID \
    --schema-registry-cluster-id schema-registry-cool-cluster
    
    Role            | ResourceType | Name | PatternType
    +---------------+--------------+------+-------------+
    SecurityAdmin   | Cluster      |      |
    
  4. Schema Registry ノードがクラスター全体の調整に使用するグループの ResourceOwner ロールをユーザーに付与します。

    confluent iam rolebinding create \
     --principal User:<sr-user-id> \
     --role ResourceOwner \
     --resource Group:<schema-registry-group-id> \
     --kafka-cluster-id <kafka-cluster-id>
    

    以下に例を示します。

    confluent iam rolebinding create \
     --principal User:jack-sr \
     --role ResourceOwner \
     --resource Group:schema-registry-cool-cluster \
     --kafka-cluster-id my-kafka-cluster-ID
    
  5. Schema Registry がそのスキーマを格納する際に使用する Kafka トピックの ResourceOwner ロールをユーザーに付与します。

    confluent iam rolebinding create \
     --principal User:<sr-user-id> \
     --role ResourceOwner \
     --resource Topic:<schemas-topic> \
     --kafka-cluster-id <kafka-cluster-id>
    

    以下に例を示します。

    confluent iam rolebinding create \
     --principal User:jack-sr \
     --role ResourceOwner \
     --resource Topic:_jax-schemas-topic \
     --kafka-cluster-id my-kafka-cluster-ID
    
  6. 作成したロールを confluent iam rolebinding list <flags> コマンドで表示します。

    confluent iam rolebinding list \
    --principal User:jack-sr \
    --role ResourceOwner \
    --kafka-cluster-id my-kafka-cluster-ID
    

    以下に例を示します。

    confluent iam rolebinding list \
    --principal User:jack-sr \
    --role ResourceOwner \
    --kafka-cluster-id my-kafka-cluster-ID
    
    Role          | ResourceType |            Name                  | PatternType
    +-------------+--------------+----------------------------------+-------------+
    ResourceOwner | Topic        | _jax-schemas-topic               | LITERAL
    ResourceOwner | Group        | schema-registry-cool-cluster     | LITERAL
    ResourceOwner | Topic        | _schemas                         | LITERAL
    ResourceOwner | Group        | schema-registry                  | LITERAL
    

クライアントの認証と認可

ライセンスクライアント認証

プリンシパル伝播を使用する場合は、SASL OAUTHBEARER(RBAC)、SASL PLAIN、SASL SCRAM および mTLS のライセンスクライアント認証を構成する必要があります。詳細については、以下のドキュメントを参照してください。

ライセンスクライアント認可

プリンシパル伝播を使用する場合は、RBAC および ACL の認可を構成する必要があります。

注釈

Confluent Platform 6.2.1 以降では、_confluent-command 内部トピックが提供されており、Schema Registry、REST Proxy、Confluent Server などの(従来は _confluent-license が使用されていた)コンポーネントで、_confluent-license トピックの代わりに使用することが推奨されています。今後は両方のトピックがサポートされます。以下に、いくつかのガイドラインを示します。

  • 新しいデプロイ(Confluent Platform 6.2.1 以降)では、以下に示すように、デフォルトで _confluent-command が使用されます。
  • 既存のクラスターでは、手動で変更しない限り、引き続き _confluent-license が使用されます。
  • Confluent Platform 6.2.1 以降で新しく作成されたクラスターでは、デフォルトで _confluent-command トピックが作成されます。_confluent-license トピックは、既にそれが適用されている既存のクラスターでのみ、引き続き使用されます。
  • RBAC による認可 次のコマンドを実行して、コンポーネントユーザーの ResourceOwner を Confluent ライセンストピックのリソース(デフォルト名は _confluent-command)に追加します。

    confluent iam rolebinding create \
    --role ResourceOwner \
    --principal User:<service-account-id> \
    --resource Topic:_confluent-command \
    --kafka-cluster-id <kafka-cluster-id>
    
  • ACL による認可 次のコマンドを実行して Kafka 認可を構成します。その際、ブートストラップサーバー、クライアント構成、サービスアカウント ID を指定します。これにより _confluent-command トピックの作成、読み取り、書き込みが許可されます。

    kafka-acls --bootstrap-server <broker-listener> --command-config <client conf> \
    --add --allow-principal User:<service-account-id>  --operation Create --operation Read --operation Write \
    --topic _confluent-command
    

(省略可)登録済みのクラスター名の使用

Confluent Platform 6.0 以降では、Schema Registry の Kafka クラスターを クラスターレジストリ に登録できます。わかりやすいクラスター名を指定できるため、ロールバインディングが作成しやすくなります。Schema Registry のサービスプリンシパルにロールを付与するすべてのサンプルコマンド(「Schema Registry の service principal に対するロールの付与」を参照)で、<schema-registry-group-id><kafka-cluster-id> の代わりに登録済みのクラスター名を使用することができます。

たとえば、登録されていないクラスターに対するロールバインディングコマンドでは、Schema Registry のグループ ID とクラスター ID の両方を指定する必要があります。

confluent iam rolebinding create \
  --principal User:<sr-user-id> \
  --role ResourceOwner \
  --resource Group:<schema-registry-group-id> \
  --kafka-cluster-id <kafka-cluster-id>

Schema Registry クラスターが Confluent Platform cluster registry に登録されている場合、<schema-registry-group-id><kafka-cluster-id> は、登録されているクラスターのわかりやすい名前に置き換えることができます。

confluent iam rolebinding create \
  --principal User:<sr-user-id> \
  --role ResourceOwner \
  --cluster-name <registered-cluster-name>

Schema Registry の起動とテスト

クリーンな状態を保つために、ローカル ZooKeeper と Kafka サーバーはシャットダウンされていることを確認してください。この例の実行対象はリモートクラスターであるため、起動する必要があるのは Schema Registry だけです。

  1. コマンドウィンドウを開いて、Confluent Platform のローカルインストールディレクトリに移動し、次のコマンドを実行して Schema Registry を起動します。

    ./bin/schema-registry-start ./etc/schema-registry/schema-registry.properties
    
  2. 次のコマンドを実行してサブジェクトを表示します。

    curl localhost:8081/subjects
    

    上記のような空の [ ] (または、角かっこで囲まれたトピック)が表示されれば成功です(空の角かっこは、まだトピックが作成されていないことを表します)。

    ローカルの Schema Registry が正常に起動していて、subjects に対する curl が正常に実行されれば、RBAC を使用して Schema Registry にアクセスできるはずです。

    ちなみに

    • 上記の curl コマンドが正しく実行されない場合は、そのコマンドと一緒に Schema Registry service principal の認証情報を送信してみてください。

      curl -u <username>:<password> localhost:8081/subjects
      
    • RBAC 対応の Confluent Control Center または curl コマンドを使用して、トピック、サブジェクト、スキーマを作成したり管理したりすることができます。「Schema Registry のチュートリアル」および「Schema Registry API の使用例」を参照してください。利用可能なリソースとアクションの範囲は、RBAC によってログイン認証情報に基づいて決定されます。

この時点で、Schema Registry は、RBAC と連携して動作するように正しく構成されています。

今度は、Confluent CLI を使用して、特定のサブジェクトを対象に、Schema Registry ユーザーにロールベースのアクセス権を付与してみましょう。

Confluent CLI にログオンして Schema Registry ユーザーにアクセス権を付与する

  1. 再度 MDS にログオンします。

    confluent login --url <http/s>://<metadata_server_url>:<port>
    
  2. my-kafka-cluster-ID という Kafka クラスターと "schema-registry-cool-cluster" という Schema Registry クラスターについて、サブジェクト "transactions" に対する ResourceOwner ロールをユーザー "sam" に付与するには、次のコマンドを使用します。

    confluent iam rolebinding create \
    --principal User:sam \
    --resource Subject:transactions \
    --role ResourceOwner \
    --kafka-cluster-id my-kafka-cluster-ID \
    --schema-registry-cluster-id schema-registry-cool-cluster