Admin REST APIs のセキュリティ

Admin REST APIs の認証

クライアントと Admin REST APIs 間の通信には、HTTP 基本認証または mutual TLS (mTLS) authentication を使用できます。Admin REST APIs と API が実行されているブローカー間の通信には、SASL または mTLS を使用できます。

重要

プリンシパル伝播がない場合、認証は REST Proxy で終了します。これは、Kafka へのすべてのリクエストが 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
    

HTTP 基本認証

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

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

  1. 以下の構成を Apache Kafka® プロパティファイル( etc/kafka/server.properties )に追加します。

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

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

    ちなみに

    KafkaRestkafka.propertieskafka.rest.authentication.realm と指定されたレルムと一致します。

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

    thisismyusername: thisismypass,thisismyrole
    
  4. HTTP 基本認証を使用して Confluent Server を起動します。

    KAFKA_OPTS="-Djava.security.auth.login.config=<path-to-confluent>/etc/kafka/server-jaas.properties" \
    bin/kafka-server-start etc/kafka/server.properties
    
  5. ユーザー名 thisismyusername とパスワード thisismypass で Confluent Server にログインします。password.properties ファイル内のパスワードはハッシュ化することもできます。詳細については、こちらのリンク を参照してください。

構成オプション

kafka.rest.authentication.method

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

  • 型: string
  • デフォルト: "NONE"
  • 重要度: 高
kafka.rest.authentication.realm

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

  • 型: string
  • デフォルト: ""
  • 重要度: 高
kafka.rest.authentication.roles

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

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

相互 TLS 認証

相互 TLS(mTLS)認証 を使用すると、クライアント側の X.509 証明書を使用して、HTTPS を有効にした Admin REST APIs で認証できます。

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

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

最後に、confluent.http.server.ssl.client.authenticationREQUIRED に設定することで mTLS を有効にできます(この設定のブール値バージョンである ssl.client.auth は非推奨)。

構成オプション

confluent.http.server.ssl.client.auth

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

代わりに confluent.http.server.ssl.client.authentication を使用してください。

  • 型: boolean
  • デフォルト: false
  • 重要度: 中
confluent.http.server.ssl.client.authentication

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

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

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

  • 型: string
  • デフォルト: NONE
  • 重要度: 中
confluent.http.server.ssl.truststore.location

トラストストアの場所。

  • 型: string
  • デフォルト: ""
  • 重要度: 高
confluent.http.server.ssl.truststore.password

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

  • 型: password
  • デフォルト: ""
  • 重要度: 高
confluent.http.server.ssl.truststore.type

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

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

Admin REST APIs ブローカーと Kafka ブローカー間の認証

Confluent Server で実行されている Admin REST APIs は、通常の Kafka Java クライアントを使用して(デフォルトでは同じブローカー上のブローカー間リスナーを使用)、内部的に Kafka ブローカーと通信します。つまり、クライアントが通信しているリスナーがセキュアな場合、前述のリスナーを経由して Kafka と通信するように Admin REST APIs Java クライアントのセキュリティパラメーターを構成する必要があります。

SASL による認証

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

すべての SASL 構成(Admin REST APIs からブローカーへの通信用)には client.、またはその代わりに admin. というプレフィックスが付いていることに注意してください。

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

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

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

または、たとえば <path-to-confluent>/etc/kafka/server-jaas.properties のように、JAAS の構成ファイルを作成することもできます。

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

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

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

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

構成オプション

kafka.rest.client.security.protocol

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

  • 型: string
  • デフォルト: PLAINTEXT
  • 重要度: 高
kafka.rest.client.sasl.jaas.config

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

  • 型: string
  • デフォルト: null
  • 重要度: 高
kafka.rest.client.sasl.kerberos.service.name

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

  • 型: string
  • デフォルト: null
  • 重要度: 中
kafka.rest.client.sasl.mechanism

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

  • 型: string
  • デフォルト: GSSAPI
  • 重要度: 中
kafka.rest.client.sasl.kerberos.kinit.cmd

Kerberos の kinit コマンドパス。

  • 型: string
  • デフォルト: /usr/bin/kinit
  • 重要度: 低
kafka.rest.client.sasl.kerberos.min.time.before.relogin

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

  • 型: long
  • デフォルト: 60000
  • 重要度: 低
kafka.rest.client.sasl.kerberos.ticket.renew.jitter

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

  • 型: double
  • デフォルト: 0.05
  • 重要度: 低
kafka.rest.client.sasl.kerberos.ticket.renew.window.factor

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

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

相互 TLS 認証

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

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

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

Kafka のブローカーが ssl.client.auth=required で設定されており、Admin REST APIs のクライアント証明書を kafka.rest.client.ssl.keystore.* で構成している場合、Admin REST APIs は Kafka のブローカーを使用して SSL 認証を行うようになります。

プリンシパル伝播

This is a commercial component of Confluent Platform.

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

重要

プリンシパル伝播がない場合、認証は REST Proxy で終了します。これは、Kafka へのすべてのリクエストが REST Proxy ユーザーとして実行されることを意味します。

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

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

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

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

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";
};

以下に、構成されたログインモジュールの 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 のオプションとして明示的に指定できます。

構成オプション

kafka.rest.confluent.rest.auth.propagate.method

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

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

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

mTLS から SASL への認証情報の伝播を有効にするには、confluent.http.server.ssl.client.authtrue に、kafka.rest.confluent.rest.auth.propagate.methodSSL に、client.security.protocolSASL_PLAINTEXT または SASL_SSL のどちらかに設定する必要があります。

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

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

構成オプション

kafka.rest.confluent.rest.auth.propagate.method

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

  • 型: string
  • デフォルト: "SSL"
  • 重要度: 低
kafka.rest.confluent.rest.auth.ssl.principal.mapping.rules

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

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

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

mTLS から mTLS への認証情報の伝播を有効にするには、confluent.http.server.ssl.client.authenticationREQUIRED (この設定のブール値バージョンである ssl.client.auth は非推奨)に、また、kafka.rest.confluent.rest.auth.propagate.methodSSL に設定する必要があります。

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

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

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

構成オプション

kafka.rest.confluent.rest.auth.propagate.method

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

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

ロールベースアクセス制御(RBAC)

This is a commercial component of Confluent Platform.

前提条件:

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

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

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

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

プリンシパル伝播を使用する場合は、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
    

構成オプション

kafka.rest.rest.servlet.initializor.classes

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

  • 型: string
  • デフォルト: ""
  • 重要度: 高
kafka.rest.kafka.rest.resource.extension.class

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

  • 型: string
  • デフォルト: PLAINTEXT
  • 重要度: 高
kafka.rest.client.security.protocol

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

  • 型: string
  • デフォルト: ""
  • 重要度: 高
kafka.rest.public.key.path

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

  • 型: string
  • デフォルト: ""
  • 重要度: 高
kafka.rest.confluent.metadata.bootstrap.server.urls

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

  • 型: string
  • デフォルト: ""
  • 重要度: 高
kafka.rest.confluent.metadata.basic.auth.user.info

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

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