REST Proxy のセキュリティ¶
REST Proxy には 2 つの異なる接続があります。1 つはクライアントへの接続、もう 1 つはブローカーへの接続です。これらの接続は区別されるものであり、それぞれについて完全に別々の異なったセキュリティ構成が必要です。つまり、 クライアントおよび REST Proxy 間の接続 と REST Proxy およびブローカー間の接続 の 2 つのセキュリティを構成する必要があります。
![../../../_images/rest-proxy-security.ja.png](../../../_images/rest-proxy-security.ja.png)
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 のライセンスクライアント認証を構成する必要があります。詳細については、以下のドキュメントを参照してください。
- ライセンスクライアント認可
プリンシパル伝播を使用する場合は、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.2.1 以降)では、以下に示すように、デフォルトで
HTTP 基本認証¶
HTTP 基本認証 により、ユーザー名とパスワードのペアを使用して REST Proxy で認証できます。これらのペアは、Authorization
HTTP ヘッダーを使用して REST Proxy サーバーに提示されます。
HTTP 基本認証を有効にするには、以下の手順に従います。
以下の構成を REST Proxy プロパティファイル(
etc/kafka-rest/kafka-rest.properties
)に追加します。authentication.method=BASIC authentication.realm=KafkaRest authentication.roles=thisismyrole
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
と指定されたレルムと一致します。パスワードのプロパティファイル(
<path-to-confluent>/etc/kafka-rest/password.properties
)を作成します。以下に例を示します。thisismyusername: thisismypass,thisismyrole
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
ユーザー名
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 のセキュリティワークフローをまとめたものです。
- ユーザーが HTTP 基本認証用の LDAP 認証情報を使用して REST Proxy への REST API 呼び出しを行います。
- REST Proxy は、認証されたユーザーのトークンを取得して、MDS でユーザーを認証します。
- 生成されたトークンは、ユーザーリクエストに偽装し、Kafka クライアントと Kafka クラスターの間で認証を行うために使用されます。Kafka クライアントの場合、
SASL_PLAINTEXT
/SASL_SSL
セキュリティプロトコルが使用され、プロプライエタリなコールバックハンドラーがトークンを Kafka クラスターに渡します。同様に、Schema Registry と通信する際、BearerAuthCredentialProvider
インターフェイスのプロプライエタリな実装を使用して認証トークンが Schema Registry クライアントに渡されます。 - リクエストされたリソース(トピック、グループ、クラスターなど)に必要なロールまたは ACL アクセス許可をユーザーが持っていない場合、REST API 呼び出しは失敗し、HTTP 403 ステータスコードでエラーを返します。
![../../../_images/rbac-rest-proxy-security.ja.png](../../../_images/rbac-rest-proxy-security.ja.png)
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 のライセンスクライアント認証を構成する必要があります。詳細については、以下のドキュメントを参照してください。
- ライセンスクライアント認可
プリンシパル伝播を使用する場合は、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.2.1 以降)では、以下に示すように、デフォルトで
構成オプション¶
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 秒)
- 重要度: 低