1. Home
2. Platform
3. Confluent REST API
4. Confluent REST API の本稼働環境のデプロイ
5. REST Proxy の本稼働環境のデプロイ

REST Proxy のセキュリティ

REST Proxy には 2 つの異なる接続があります。1 つはクライアントへの接続、もう 1 つはブローカーへの接続です。これらの接続は区別されるものであり、それぞれについて完全に別々の異なったセキュリティ構成が必要です。つまり、 クライアントおよび REST Proxy 間の接続 と REST Proxy およびブローカー間の接続 の 2 つのセキュリティを構成する必要があります。

REST Proxy のセキュリティワークフロー

接続が初期化されると、REST Proxy に対して基本的な処理リクエストが行われます。そのようなリクエストはプレーンテキストまたは JSON で、Kafka に保管されるメタデータとコンテンツ、または Kafka からデータを取得するリクエストを含みます。REST Proxy はこれらのリクエストを受け取り、Kafka リクエストに変換して、Kafka ブローカーで処理します。

REST Proxy では（ Schema Registry と異なり）実際には認可が行われないため、制限を適用するにはブローカー ACL を設定する必要があります。

REST Proxy の認証

クライアントと REST Proxy の間の通信には、HTTP 基本認証または mutual TLS (mTLS) authentication を使用できます。REST Proxy とブローカーの間の通信には、SASL または mTLS を使用できます。

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

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

• 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 rbac role-binding 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
  

HTTP 基本認証

HTTP 基本認証 により、ユーザー名とパスワードのペアを使用して REST Proxy で認証できます。これらのペアは、Authorization HTTP ヘッダーを使用して REST Proxy サーバーに提示されます。

HTTP 基本認証を有効にするには、以下の手順に従います。

1. 以下の構成を REST Proxy プロパティファイル（etc/kafka-rest/kafka-rest.properties）に追加します。

   authentication.method=BASIC
   authentication.realm=KafkaRest
   authentication.roles=thisismyrole
   

2. JAAS の構成ファイルを作成します。たとえば、<path-to-confluent>/etc/kafka-rest/rest-jaas.properties のようなものです。

   KafkaRest {
       org.eclipse.jetty.jaas.spi.PropertyFileLoginModule required
       debug="true"
       file="<path-to-confluent>/etc/kafka-rest/password.properties";
   };
   

   ちなみに

   KafkaRest は kafka-rest.properties で authentication.realm と指定されたレルムと一致します。

3. パスワードのプロパティファイル（ <path-to-confluent>/etc/kafka-rest/password.properties ）を作成します。以下に例を示します。

   thisismyusername: thisismypass,thisismyrole
   

4. REST Proxy を HTTP 基本認証で開始します。

   KAFKAREST_OPTS="-Djava.security.auth.login.config=<path-to-confluent>/etc/kafka-rest/rest-jaas.properties" \
   bin/kafka-rest-start etc/kafka-rest/kafka-rest.properties
   

5. ユーザー名 thisismyusername とパスワード thisismypass で REST Proxy にログインします。password.properties ファイル内のパスワードはハッシュ化することもできます。詳細については、こちらのリンク を参照してください。

構成オプション

authentication.method

REST Proxy がリクエストの認証に使用するメソッドを指定します。NONE または BASIC のどちらかです。HTTP 基本認証をアクティブにするには、BASIC に設定する必要があります。

• 型: string
• デフォルト: "NONE"
• 重要度: 高

authentication.realm

authentication.method = BASIC の場合、この構成は、システムの JAAS 構成ファイルのどのセクションを使用して HTTP 基本認証情報を認証するかを指定します。

• 型: string
• デフォルト: ""
• 重要度: 高

authentication.roles

authentication.method = BASIC の場合、この構成は、HTTP 基本認証でどのユーザーロールに REST Proxy での認証を許可するかを指定します * に設定されている場合、どのロールでも認証が許可されます。

• 型: string
• デフォルト : "*"
• 重要度: 中

相互 TLS 認証

相互 TLS（mTLS）認証 により、クライアント側の X.509 証明書を使用して、HTTPS を有効にした REST Proxy で認証できます。

mTLS を有効にするには、まず REST Proxy で HTTPS を有効にする必要があります。設定する必要のある構成オプションについては、「Confluent REST API での HTTPS の構成オプション」を参照してください。

​HTTPS を構成したら、着信クライアント X.509 証明書を検証できるように REST Proxy トラストストアを構成する必要があります。たとえば、読み込まれたクライアント証明書の署名に使用されるルート CA 証明書を持つキーストアを指すように REST Proxy トラストストアを構成できます。

最後に、ssl.client.authentication を REQUIRED に設定して mTLS を有効にできます。

構成オプション

ssl.client.auth

非推奨: HTTPS に使用します。サーバーのトラストストアを使用した認証を HTTPS クライアントに要求するかどうかを指定します。mTLS を有効にするには、true に設定する必要があります。代わりに ssl.client.authentication を使用してください。

• 型: boolean
• デフォルト: false
• 重要度: 中

ssl.client.authentication

HTTPS に使用されます。サーバーのトラストストアを使用した認証を HTTPS クライアントに要求するかどうかを指定します。mTLS を有効にするには、REQUIRED に設定する必要があります。

この構成は、非推奨となった ssl.client.auth をオーバーライドします。

指定可能な値は、NONE、REQUESTED、REQUIRED のいずれかです。NONE を指定した場合、TLS/SSL クライアント認証が無効になります。REQUESTED を指定した場合、TLS/SSL クライアント認証はリクエストされますが、必須ではありません。REQUIRED を指定した場合、TLS/SSL HTTPS クライアントは、サーバーのトラストストアを使用して認証を行う必要があります。

• 型: string
• デフォルト: NONE
• 重要度: 中

ssl.truststore.location

トラストストアの場所。

• 型: string
• デフォルト: ""
• 重要度: 高

ssl.truststore.password

トラストストアファイルのパスワード。

• 型: password
• デフォルト: ""
• 重要度: 高

ssl.truststore.type

トラストストアファイルの種類。

• 型: string
• デフォルト: JKS
• 重要度: 中

REST Proxy ブローカーと Kafka ブローカーの間の認証

セキュアな Kafka ブローカーと通信するために REST Proxy を使用している場合、Kafka で認証できるように適切な認証情報で REST Proxy を構成する必要があります。Kafka は SASL および mTLS で認証するように構成できます。以下のセクションでは、それぞれの認証について REST Proxy を構成する方法を詳しく説明します。

SASL の認証

Kafka SASL 構成については こちら で説明しています。

すべての SASL 構成（REST Proxy からブローカーへの通信用）には client. というプレフィックスが付いていることに注意してください。管理者のみ、コンシューマーのみ、またはプロデューサーのみに構成を適用する場合は、プレフィックスを admin.、consumer.、または producer. に置き換えてください。

重要

bootstrap.servers の構成に SASL_PLAINTEXT://host:port （または SASL_SSL://host:port ）エンドポイントが設定されていることを確認してください。このように設定されていない場合、誤って非 SASL ポートへの SASL 接続を開いてしまいます。

Kafka ブローカーで SASL 認証を有効にするには、client.security.protocol を SASL_PLAINTEXT または SASL_SSL のどちらかに設定します。

その後、Kafka で認証するために REST Proxy が使用する認証情報を client.sasl.jaas.config に設定します。以下に例を示します。

client.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="kafkarest" password="kafkarest";

または、etc/kafka-rest/etc/kafka-rest/rest-jaas.properties のような JAAS 構成ファイルを作成することもできます。

KafkaClient {
  org.apache.kafka.common.security.plain.PlainLoginModule required
  username="kafkarest"
  password="kafkarest";
};

JAAS ファイルでのセクションの名前は KafkaClient でなければなりません。これを JVM 引数として渡します。

export KAFKAREST_OPTS="-Djava.security.auth.login.config=<path-to-confluent>/etc/kafka-rest/rest-jaas.properties"

Kerberos の構成に関する詳細については、JDK の『Kerberos Requirements』を参照してください。

構成オプション

client.security.protocol

ブローカーとの通信に使用されるプロトコル。指定可能な値は、PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL です。

• 型: string
• デフォルト: PLAINTEXT
• 重要度: 高

client.sasl.jaas.config

JAAS の構成ファイルで使用される形式で記述された、SASL 接続の JAAS ログインコンテキストパラメーター。JAAS 構成ファイルの形式は、Oracle のドキュメント に記載されています。値の形式は「(=)*;」です。

• 型: string
• デフォルト: null
• 重要度: 高

client.sasl.kerberos.service.name

Kafka が実行される際の Kerberos プリンシパル名。これは、Kafka の JAAS 構成または Kafka の構成のどちらかで定義できます。

• 型: string
• デフォルト: null
• 重要度: 中

client.sasl.mechanism

クライアントの接続に使用される SASL メカニズム。セキュリティプロバイダーを利用できるものであれば、どのメカニズムでも構いません。GSSAPI がデフォルトのメカニズムです。

• 型: string
• デフォルト: GSSAPI
• 重要度: 中

client.sasl.kerberos.kinit.cmd

Kerberos の kinit コマンドパス。

• 型: string
• デフォルト: /usr/bin/kinit
• 重要度: 低

client.sasl.kerberos.min.time.before.relogin

更新試行から次の更新試行までの、ログインスレッドのスリープ時間。

• 型: long
• デフォルト: 60000
• 重要度: 低

client.sasl.kerberos.ticket.renew.jitter

更新時間に追加されたランダムジッターのパーセンテージ。

• 型: double
• デフォルト: 0.05
• 重要度: 低

client.sasl.kerberos.ticket.renew.window.factor

最後の更新からチケットの有効期限までの時間が指定のウィンドウ係数に達するまでの間、ログインスレッドはスリープ状態になります。この時間の経過後、チケットの更新が試行されます。

• 型: double
• デフォルト: 0.8
• 重要度: 低

相互 TLS 認証

Kafka TLS/SSL 構成については こちら で説明しています。

REST Proxy から Kafka への TLS/SSL 構成については こちら で説明しています。

Kafka ブローカーで mTLS を有効にするには、client.security.protocol を SSL または SASL_SSL に設定する必要があります。

Kafka ブローカーで ssl.client.authentication=required が構成されていて、REST Proxy のクライアント証明書で client.ssl.keystore.* を構成している場合、REST Proxy は Kafka のブローカーを使用して TLS/SSL 認証を行います。

プリンシパル伝播

This is a commercial component of Confluent Platform.

プリンシパル伝播では、クライアント向けに構成された認証メカニズムからプリンシパルを取得して REST Proxy に伝え、Kafka ブローカーに対してリクエストを行う際に同じプリンシパルを伝播します。

セキュリティの観点から見ると、最初の JSON リクエスト（HTTP 経由）で認証が行われ、REST Proxy はこの HTTP 認証で使用されるプリンシパルを Kafka ブローカーに対して認証可能なプリンシパル（SSL/SASL）に変換します。たとえば、両方の段階で TLS/SSL を使用する場合は、REST Proxy のクライアント TLS/SSL 証明書も必要です。

伝播するすべてのプリンシパルの認証情報が、REST Proxy サーバーに存在する必要があります。これには、技術的な課題（TLS/SSL プリンシパルを Kerberos プリンシパルにマップする必要があるなど）とセキュリティ上の課題（ユーザーの偽装のために必要なものがすべて、ユーザーが制御できない REST Proxy に保管されている）の両方が関係することに注意してください。

プリンシパル伝播を使用するには、REST Proxy セキュリティプラグイン が必要です。

HTTP 基本認証から SASL 認証への認証情報の伝播

HTTP 基本認証から SASL 認証への認証情報の伝播を有効にするには、authentication.method を BASIC に、confluent.rest.auth.propagate.method を JETTY_AUTH に、client.security.protocol を SASL_PLAINTEXT または SASL_SSL のどちらかに設定する必要があります。

セキュリティプラグインは、Kafka クライアントがサポートするすべての sasl.mechanism をサポートします。通常の Kafka クライアントと同様、このプラグインも JAAS 構成ファイルが -Djava.security.auth.login.config を使用して構成されると想定します。JAAS 構成ファイルのセクション KafkaClient で、すべてのプリンシパルを指定する必要があります。

JAAS 構成ファイルでは、すべてのプリンシパルを明示的に指定する必要があります。プラグインは、サポートされるメカニズム（ GSSAPI、PLAIN、SCRAM-SHA-256、および SCRAM-SHA-512 ）を使用したプリンシパルの指定に対応しています。また、プラグインは構成されている sasl.mechanism を無視し、プリンシパルに指定されている LoginModule に基づいて自動的にプリンシパルを選択します。

JAAS ファイルには、こちら に記載されている基本認証のロジックも含まれている必要があります。この例では、KafkaClient {...} ブロックで SASL 認証が提供され、末尾の KafkaRest {...} ブロックで基本認証のロジックが提供されています。

KafkaClient {
  com.sun.security.auth.module.Krb5LoginModule required
  useKeyTab=true
  storeKey=true
  keyTab="/etc/security/keytabs/restproxy-localhost.keytab"
  principal="CN=restproxy/localhost@EXAMPLE.COM";

  com.sun.security.auth.module.Krb5LoginModule required
  useKeyTab=true
  storeKey=true
  keyTab="/etc/security/keytabs/kafka_client_2.keytab"
  principal="kafka-client-2@EXAMPLE.COM";

  org.apache.kafka.common.security.plain.PlainLoginModule required
  username="alice-plain"
  password="alice-secret";

  org.apache.kafka.common.security.scram.ScramLoginModule required
  username="alice-scram"
  password="alice-secret";

  org.apache.kafka.common.security.scram.ScramLoginModule required
  username="alice-scram-256"
  password="alice-secret"
  mechanism="SCRAM-SHA-256";
};

KafkaRest {
    org.eclipse.jetty.jaas.spi.PropertyFileLoginModule required
    debug="true"
    file="<path-to-confluent>/etc/kafka-rest/password.properties";
};

以下に、構成されたログインモジュールの sasl.mechanism のマッピングを示します。

プリンシパルのログインモジュール	SASL メカニズム
com.sun.security.auth.module.Krb5LoginModule	GSSAPI
org.apache.kafka.common.security.plain.PlainLoginModule	PLAIN
org.apache.kafka.common.security.scram.ScramLoginModule	SCRAM-SHA-512 SCRAM-SHA-256 の場合は、 mechanism=SCRAM-SHA-256 を ScramLoginModule のオプションとして設定

SCRAM-SHA-256 以外のすべてのメカニズムはプラグインによって自動的に検出され、SCRAM-SHA-256 は ScramLoginModule のオプションとして明示的に指定できます。

構成オプション

confluent.rest.auth.propagate.method

REST Proxy リクエストの認証に使用されるメカニズム。ブローカーのセキュリティが有効な場合、この認証メカニズムからのプリンシパルが Kafka ブローカーのリクエストに伝搬されます。JETTY_AUTH または SSL のどちらかです。

• 型: string
• デフォルト: "SSL"
• 重要度: 低

mTLS から SASL への認証情報の伝播

mTLS から SASL への認証情報の伝播を有効にするには、ssl.client.auth を true に、confluent.rest.auth.propagate.method を SSL に、client.security.protocol を SASL_PLAINTEXT または SASL_SSL のどちらかに設定する必要があります。

クライアントから着信する X 500 プリンシパルは、Kafka ブローカーとの対話中にプリンシパルとして使用されます。confluent.rest.auth.ssl.principal.mapping.rules を使用して、クライアント証明書からプリンシパルの伝播に使用できる名前に DN をマップできます。たとえば、RULE:^CN=(.*?)$/$1/ のようなルールは、DN の CN= の部分を除去します。

すべてのプリンシパル、およびそのログインモジュールとオプションを含む KafkaClient セクションを持つ JAAS の構成ファイルが必要で、これは -Djava.security.auth.login.config を使用して構成されます。

構成オプション

confluent.rest.auth.propagate.method

REST Proxy リクエストの認証に使用されるメカニズム。ブローカーのセキュリティが有効な場合、この認証メカニズムからのプリンシパルが Kafka ブローカーのリクエストに伝搬されます。

• 型: string
• デフォルト: "SSL"
• 重要度: 低

confluent.rest.auth.ssl.principal.mapping.rules

クライアント証明書の識別名（DN）を短い名前にマッピングするためのルールのリスト。ルールは順番に評価され、プリンシパル名と一致する最初のルールが、短い名前へのマッピングに使用されます。リスト内のそれ以降のルールはすべて無視されます。デフォルトでは、X.500 証明書の DN がプリンシパルになります。各ルールは "RULE:" で始まり、以下の形式を使用した式が含まれます。デフォルトのルールは、X.500 証明書 DN の文字列表現を返します。DN がパターンと一致する場合、置換コマンドがその名前に対して実行されます。このコマンドは小文字と大文字のオプションもサポートしており、変換結果を強制的にすべて小文字または大文字に置き換えます。この処理は、ルールの末尾に "/L" または "/U' を追加することによって実行されます。

• 型: list
• デフォルト: DEFAULT
• 重要度: 低

注釈

REST Proxy を使用した mTLS（SSL）から SASL への伝播を構成するには、confluent.rest.auth.ssl.principal.mapping.rules のみを使用します。これは、REST Proxy を使用した SSL から SSL への伝播 を構成する場合には使用しないでください。

TLS 認証から TLS 認証への認証情報の伝播

mTLS から mTLS への認証情報の伝播を有効にするには、ssl.client.authentication を REQUIRED に、confluent.rest.auth.propagate.method を SSL に設定する必要があります。

TLS/SSL 伝播を機能させるには、必要なプリンシパルに対応するすべての証明書を 1 つのクライアントキーストアファイルに読み込む必要があります。これが完了すると、プラグインは Kafka にリクエストを行うときに、ログオンしたプリンシパルに基づいて適切な証明書エイリアスを選択します。現時点では、ログオンしたプリンシパルは、証明書の X.509 プリンシパルと正確に一致する必要があります。

たとえば、2 つのクライアントが REST Proxy に統合されている場合、セットアップは以下のように簡単なものになります。

• "クライアント A" は、"証明書-A" を含むキーストアを使用して REST Proxy に対して認証します。
• "クライアント B" は、"証明書-B" を含むキーストアを使用して REST Proxy に対して認証します。
• REST Proxy のキーストア client.ssl.keystore.location が "証明書-A" および "証明書-B" とともに読み込まれます。その後、クライアントがどれであるかに基づいてプラグインで証明書が選択されます。

構成オプション

confluent.rest.auth.propagate.method

REST Proxy リクエストの認証に使用されるメカニズム。ブローカーのセキュリティが有効な場合、この認証メカニズムからのプリンシパルが Kafka ブローカーのリクエストに伝搬されます。

• 型: string
• デフォルト: "SSL"
• 重要度: 低

注釈

REST Proxy のみを使用した mTLS（TLS/SSL）から SASL への伝播 を構成するには、confluent.rest.auth.ssl.principal.mapping.rules を使用します。これは、REST Proxy を使用した TLS/SSL から TLS/SSL への伝播を構成する場合には使用しないでください。

ロールベースアクセス制御（RBAC）

This is a commercial component of Confluent Platform.

前提条件:

• RBAC が有効になった Kafka および Schema Registry クラスター。RBAC の詳細については、「ロールベースアクセス制御を使用した認可」を参照してください。

HTTPS をお勧めしますが、必須ではありません。

Confluent REST Proxy は、クロスコンポーネントのプロプライエタリなロールベースアクセス制御（RBAC）ソリューションをサポートしており、Confluent Platform 全体にアクセス制御を適用します。REST Proxy セキュリティプラグインは、Bearer トークンベースの認証メカニズムをサポートします。トークン認証を使用すると、Kafka ブローカーおよび Schema Registry クラスターと通信する際に REST Proxy はユーザーリクエストに偽装できます。

RBAC REST Proxy のセキュリティによって、以下のようなさまざまなユーザビリティの課題が解決されます。

• プリンシパルのローカル構成。RBAC REST Proxy のセキュリティでは、プリンシパルをローカルで構成するのではなく、Metadata Service（MDS）によって処理するようになっています。
• 既存の REST Proxy のセキュリティ機能は、大規模なデプロイの場合、相当な量の手作業を行わないと拡張できません。RBAC REST Proxy のセキュリティでは、MDS がさまざまなリソース（トピック、コネクター、Schema Registry など）を横断して Kafka クラスター構成をバインドして適用するため、ユーザーは ACL とロールを各 Kafka クラスターリソースごとに個別に再構成するための時間と手間を省くことができます。

RBAC REST Proxy のワークフロー

以下は、RBAC REST Proxy のセキュリティワークフローをまとめたものです。

1. ユーザーが HTTP 基本認証用の LDAP 認証情報を使用して REST Proxy への REST API 呼び出しを行います。
2. REST Proxy は、認証されたユーザーのトークンを取得して、MDS でユーザーを認証します。
3. 生成されたトークンは、ユーザーリクエストに偽装し、Kafka クライアントと Kafka クラスターの間で認証を行うために使用されます。Kafka クライアントの場合、SASL_PLAINTEXT/SASL_SSL セキュリティプロトコルが使用され、プロプライエタリなコールバックハンドラーがトークンを Kafka クラスターに渡します。同様に、Schema Registry と通信する際、BearerAuthCredentialProvider インターフェイスのプロプライエタリな実装を使用して認証トークンが Schema Registry クライアントに渡されます。
4. リクエストされたリソース（トピック、グループ、クラスターなど）に必要なロールまたは ACL アクセス許可をユーザーが持っていない場合、REST API 呼び出しは失敗し、HTTP 403 ステータスコードでエラーを返します。

RBAC REST Proxy のセキュリティワークフロー

RBAC REST Proxy のセキュリティの構成

RBAC を REST Proxy で使用するには、 REST Proxy セキュリティプラグイン が必要です。

トークン認証を（ kafka-rest.properties ファイルで）有効にするには、rest.servlet.initializor.classes を io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler に、kafka.rest.resource.extension.class を io.confluent.kafkarest.security.KafkaRestSecurityResourceExtension に設定します。

rest.servlet.initializor.classes=io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler
kafka.rest.resource.extension.class=io.confluent.kafkarest.security.KafkaRestSecurityResourceExtension

トークン認証を有効にすると、生成されたトークンを使用して API リクエストの偽装が行われます。REST Proxy Kafka クライアントは、SASL_PLAINTEXT または SASL_SSL 認証メカニズムを使用して Kafka ブローカーで認証します。

Metadata Service（MDS）で使用する資格情報を指定します。この資格情報は通常、Kafka との通信に使用するものと一致する必要があります。

confluent.metadata.basic.auth.user.info=<username>:<password>
confluent.metadata.http.auth.credentials.provider=BASIC

注釈

Schema Registry から MDS へのリクエストのレイテンシが高い場合は、オプションの設定 confluent.metadata.http.request.timeout.ms のタイムアウト値を大きくして、レイテンシの高さに対応できるようにします。再試行に十分な時間的余裕を確保できるように、オプションの設定 confluent.metadata.request.timeout.ms で指定されている値を相応に大きくすることが必要な場合があります。オプションの構成設定の詳細については、RBAC REST Proxy の構成オプション を参照してください。

「トークン認証の構成」も参照してください。

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

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

• 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 rbac role-binding 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
  

構成オプション

rest.servlet.initializor.classes

REST Proxy のカスタム初期化クラスのリスト。RBAC を使用するには、io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler に設定します。

• 型: string
• デフォルト: ""
• 重要度: 高

kafka.rest.resource.extension.class

REST Proxy のカスタム拡張クラスのリスト。RBAC を使用するには、io.confluent.kafkarest.security.KafkaRestSecurityResourceExtension に設定します。

• 型: string
• デフォルト: PLAINTEXT
• 重要度: 高

client.security.protocol

ブローカーとの通信に使用されるプロトコル。指定可能な値は、PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL です。RBAC を使用するには、SASL_PLAINTEXT または `SASL_SSL のどちらかに設定します。

• 型: string
• デフォルト: ""
• 重要度: 高

public.key.path

トークンの検証に使用される PEM エンコードされたパブリックキーファイルの場所。

• 型: string
• デフォルト: ""
• 重要度: 高

confluent.metadata.bootstrap.server.urls

この REST Proxy が接続するブートストラップメタデータサービスの URL のコンマ区切りのリスト。たとえば、http://localhost:8080,http://localhost:8081 のように指定します。

• 型: string
• デフォルト: ""
• 重要度: 高

confluent.metadata.basic.auth.user.info

user:password の形式で表したサービスユーザーの認証情報。

• 型: string
• デフォルト: ""
• 重要度: 高

confluent.metadata.http.auth.credentials.provider

Metadata Server（MDS）認証プロバイダー（BASIC など）。

• 型: string
• デフォルト: ""
• 重要度: 高

次のオプション設定を使用して HTTP クライアントを内部的に構成し、MDS を呼び出して REST Proxy クライアントを認可することができます。

confluent.metadata.http.request.timeout.ms

オプション。クライアントが HTTP リクエストに対する応答を待機する時間の最大値を制御します。タイムアウト時間が経過するまで応答を受信できなかった場合、クライアントは、リクエストを再送し、すべての URL を使用し尽くした場合は、リクエストを失敗とします。この値は、confluent.metadata.request.timeout.ms の値以下である必要があります。

• 型: string
• デフォルト: 10000 ミリ秒（10 秒）
• 重要度: 低

confluent.metadata.request.timeout.ms

オプション。クライアントが各オーソライザーリクエストに対する応答を待機する時間の最大値を制御します。

• 型: string
• デフォルト: 30000 ミリ秒（30 秒）
• 重要度: 低