1. Home
  2. Platform
  3. スキーマ管理
  4. Schema Registry のセキュリティ

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 は現在、Kafka のセキュリティ機能をすべてサポートしています。以下はその例です。

構成の詳細については、 構成オプション を参照してください。

参考

セキュアな Kafka クラスターに対するセキュリティが構成された Schema Registry を使用する例については、「Confluent Platform のデモ」を参照してください。

Kafka クラスターに対する Schema Registry

Kafka ストア

Kafka は、Schema Registry のストレージバックエンドとして使用されます。単一のパーティションを持つ特殊な Kafka のトピック <kafkastore.topic> （デフォルトでは _schemas）は、高可用性の先書きログとして使用されます。すべてのスキーマ、サブジェクト/バージョン、ID のメタデータ、互換性設定は、このログにメッセージとして追加されます。したがって、Schema Registry インスタンスは、_schemas トピックのメッセージを生成したり消費したりすることになります。たとえば、サブジェクトに新しいスキーマが登録されたり、互換性設定に対するアップデートが登録されたりすると、このログにメッセージが生成されます。Schema Registry は、バックグラウンドスレッドで _schemas ログからメッセージを消費します。新しい _schemas メッセージを消費するたびに、そのローカルキャッシュをアップデートすることで、新しく追加されたスキーマや互換性設定を反映します。このように、Kafka ログからローカルの状態をアップデートすることで、堅牢性と順序、さらに回復の容易性が確保されています。

ちなみに

Schema Registry のトピックは圧縮されるため、Kafka 保持ポリシーに関係なく、常時、各キーの最新の値が保持されます。これは kafka-configs で確認できます。

kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name _schemas --describe

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

Configs for topic '_schemas' are cleanup.policy=compact

Schema Registry では、Kafka のすべてのセキュリティ機能がサポートされています。

Schema Registry にアクセスする必要のあるサービスはそう多くはありません。また、それらは内部的なサービスである可能性が高いため、ファイアウォールルールやネットワークセグメンテーションによって Schema Registry 自体へのアクセスを制限できます。

参考

スキーマトピックへのアクセスの認可

ZooKeeper

重要

Schema Registry では、ZooKeeper に対する SASL 認証と未認証の両方がサポートされます。

Schema Registry に対する ZooKeeper の SASL 認証をセットアップする作業は、Kafka の場合と似ています。つまり、Schema Registry に対するキータブを作成し、JAAS の構成ファイルを作成して、適切な JAAS Java プロパティを設定します。

キータブと JAAS のセットアップに加え、 zookeeper.set.acl 設定にも注意してください。この設定を true にすると、ZooKeeper の ACL が有効になり、znode へのアクセスが制限されます。

重要 : zookeeper-set-acl が true に設定されている場合、Schema Registry のサービス名は Kafka のサービス名（デフォルトでは kafka）と同じである必要があります。それ以外の場合、Schema Registry が _schemas トピックの作成に失敗し、"leader not available" エラーが DEBUG ログに出力されます。ZooKeeper の ACL が Kafka では設定されていないにもかかわらず、Schema Registry では設定されている場合、Schema Registry ログには、org.apache.kafka.common.errors.TimeoutException: Timeout expired while fetching topic metadata と記録されます。Schema Registry のサービス名は、kafkastore.sasl.kerberos.service.name で設定できるほか、JAAS ファイルで設定することもできます。

Schema Registry のサービス名が Kafka と異なる場合、Schema Registry と Kafka の両方で、zookeeper.set.acl を false に設定する必要があります。

Schema Registry のクライアント

REST API の HTTP または HTTPS の構成

Schema Registry の REST API は、デフォルトでは HTTP でクライアントから呼び出すことができます。HTTP と HTTPS のどちらか、または両方を同時に使用できるよう、Schema Registry を構成することができます。

Schema Registry で使用されるプロトコルは、次の構成によって決まります。

listeners

HTTP と HTTPS のどちらか、または両方で API リクエストをリッスンするリスナーのコンマ区切りリストです。リスナーが HTTPS を使用する場合は、適切な SSL 構成パラメーターも設定する必要があります。

Schema Registry のリスナー構成に合わせて、クライアントの schema.registry.url を構成します。

HTTPS 用の追加構成

HTTPS リスナーを構成した場合、Schema Registry に対する構成をいくつか追加で行う必要があります。

まず、（schema-registry.properties などで）適切な SSL 構成を Schema Registry クラスターのキーストアに対して行い、さらに必要に応じてトラストストアに対しても行います。トラストストアに対する構成が必要になるのは、ssl.client.auth が true に設定されている場合のみです。

ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks
ssl.truststore.password=<password>
ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks
ssl.keystore.password=<password>
ssl.key.password=<password>

Schema Registry のインスタンス間の呼び出し中に使用するプロトコルを指定できます。指定したプロトコルが、セカンダリノードからプライマリノードへの、書き込みや削除を目的とした呼び出しに使用されます。

inter.instance.protocol

Schema Registry インスタンス間の呼び出し中に使用されるプロトコルです。指定したプロトコルが、セカンダリノードからプライマリノードへの、書き込みや削除を目的とした呼び出しに使用されます。デフォルト値は http です。https が設定された場合、ssl.keystore. と ssl.truststore. の構成が呼び出し中に使用されます。schema.registry.inter.instance.protocol 名は非推奨です。inter.instance.protocol を使用してください。

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

Confluent Platform 5.4 以降には、Schema Registry 専用のクライアント構成プロパティが用意されています（例 を参照）。

ちなみに

Schema Registry のクライアントには、次の両方のソフトウェアが含まれます。

  • 開発者によって作成または使用されるクライアントアプリケーション
  • Confluent Platform のコンポーネント（Confluent Control Center、Kafka Connect、ksqlDB など）

Schema Registry に対して HTTPS を使用するようにクライアントを構成するには、次のプロパティまたは環境変数を設定します。

  1. HTTPS のリスナー構成に合わせて、クライアントの schema.registry.url を構成します。

    <client>.schema.registry.url: "<schema-registry-url>:<port>"

  2. クライアントの環境変数の構成で、SSL のキーストアとトラストストアを設定します。次の 2 つの方法のいずれかを使用してください。

    • （推奨） Schema Registry 専用プロパティを使用してクライアントを構成

      <client>.schema.registry.ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks
<client>.schema.registry.ssl.truststore.password=<password>
<client>.schema.registry.ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks
<client>.schema.registry.ssl.keystore.password=<password>
<client>.schema.registry.ssl.key.password=<password>

      Confluent Control Center の構成に使用される命名規則は、他のクライアントとは若干異なります。Schema Registry に対する HTTPS クライアントとして Control Center を構成するには、Control Center の構成ファイルでこれらの専用プロパティを指定してください。

      confluent.controlcenter.schema.registry.schema.registry.ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks
confluent.controlcenter.schema.registry.schema.registry.ssl.truststore.password=<password>
confluent.controlcenter.schema.registry.schema.registry.ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks
confluent.controlcenter.schema.registry.schema.registry.ssl.keystore.password=<password>
confluent.controlcenter.schema.registry.schema.registry.ssl.key.password=<password>

      参考

      この構成に使用される命名規則について詳しくは、 Control Center 用の「SSL の構成」 の「Schema Registry に対する TLS/SSL プロキシサーバーアクセスの構成」を参照してください。

    • （従来）クライアントに応じた環境変数を設定する（KAFKA_OPTS、SCHEMA_REGISTRY_OPTS、KSQL_OPTS のいずれか）。

      export JAVA_OPTS: "-Djavax.net.ssl.trustStore=/etc/kafka/secrets/kafka.client.truststore.jks \
            -Djavax.net.ssl.trustStorePassword=<password> \
            -Djavax.net.ssl.keyStore=/etc/kafka/secrets/kafka.client.keystore.jks \
            -Djavax.net.ssl.keyStorePassword=<password>"

重要

  • システムの環境変数で SSL の値を定義するという従来の方法を用いた場合、その JVM 上で実行されているすべての Java コンポーネントに SSL の設定が適用されます。たとえば、Connect 上のすべての コネクター で、指定したトラストストアが使用されます。仮に、Amazon Web Servces（AWS）コネクター（S3、Kinesis など）を使用しているとき、指定されたトラストストアに AWS の証明書チェーンが存在しないと、コネクターで次のエラーが発生します。

    com.amazonaws.SdkClientException: Unable to execute HTTP request:
sun.security.validator.ValidatorException: PKIX path building failed

    このことは、Schema Registry 専用のクライアント構成を使用する場合には当てはまりません。

  • kafka-avro-console-producer および kafka-avro-console-consumer では、コマンドラインで Schema Registry のプロパティを渡す必要があります。次に示したのは、プロデューサーの例です。

    ./kafka-avro-console-producer --broker-list localhost:9093 --topic myTopic \
--producer.config ~/ect/kafka/producer.properties --property value.schema=‘{“type”:“record”,“name”:“myrecord”,“fields”:[{“name”:“f1”,“type”:“string”}]}’ \
--property schema.registry.url=https://localhost:8081 --property schema.registry.ssl.truststore.location=/etc/kafka/security/schema.registry.client.truststore.jks --property schema.registry.ssl.truststore.password=myTrustorePassword

    その他、プロデューサーとコンシューマーのコマンドラインユーティリティを使用する例については、「Avro スキーマの使用例」、「JSON Schema の使用例」、「Protobuf Schema の体験」、および「Confluent Server 上の Schema Validation」のデモを参照してください。

参考

デモと例は、「Confluent Platform のデモ（cp-demo）」と「Kafka クライアントアプリケーションの例」の他、「API の使用例」の「HTTPS での Schema Registry の使用」にも掲載しています。

HTTP から HTTPS への移行

HTTPS で REST API を呼び出すことができるように既存のクラスターの Schema Registry をアップグレードするには、次の作業を行います。

  • HTTPS を含むように listeners の構成を追加または変更します。（例: http://0.0.0.0:8081、https://0.0.0.0:8082）。
  • キーストアと（必要に応じて）トラストストアをセットアップするための適切な SSL 構成を使用して Schema Registry を構成します。
  • クラスターのローリング再起動を実行します。

このプロセスで HTTPS は有効になりますが、すべてのノードの再起動が完了するまでは、Schema Registry インスタンスが通信を継続できるよう、デフォルトは HTTP のままになります。HTTP を使用しないように構成するまでは、引き続き HTTP がデフォルトとして使用されます。HTTPS がデフォルトとなるように切り替えて、HTTP のサポートを無効にするには、次の手順に従います。

  • アップグレードの最初のセクションで言及したように HTTPS を有効にします（HTTP と HTTPS の両方が有効になります）。
  • すべてのノードの inter.instance.protocol を https に構成します。
  • クラスターのローリング再起動を実行します。
  • すべてのノードの listeners から http リスナーを削除します。
  • クラスターのローリング再起動を実行します。

REST API の HTTP 基本認証の構成

Schema Registry を構成することにより、HTTP 基本認証メカニズムを介し、ユーザー名とパスワードを使用して認証するようユーザーに要求することができます。

注釈

基本認証を使用する場合、基本プロトコルでは資格情報がプレーンテキストで渡されるため、セキュアな通信用に HTTPS が使用されるようにスキーマレジストリを構成 することをお勧めします。

認証を要求するように Schema Registry を構成するには、次の設定を使用します。

authentication.method=BASIC
authentication.roles=<user-role1>,<user-role2>,...
authentication.realm=<section-in-jaas_config.conf>

authentication.roles 構成では、ユーザーロールのコンマ区切りリストを定義します。Schema Registry にアクセスするための認可を受けるには、認証されたユーザーがこれらのロールの 1 つ以上に属している必要があります。

たとえば、admin、developer、user、sr-user の各ロールを定義する場合、次の構成でこれらのロールを認証用に割り当てます。

authentication.roles=admin,developer,user,sr-user

authentication.realm 構成は、jaas_config.conf 内のセクションと一致する必要があります。これは、サーバーによるユーザーの認証方法を定義し、サーバーの起動時に JVM オプションとして渡されます。

export SCHEMA_REGISTRY_OPTS=-Djava.security.auth.login.config=/path/to/the/jaas_config.conf
<path-to-confluent>/bin/schema-registry-start <path-to-confluent>/etc/schema-registry/schema-registry.properties

jaas_config.conf の例を以下に示します。

SchemaRegistry-Props {
  org.eclipse.jetty.jaas.spi.PropertyFileLoginModule required
  file="/path/to/password-file"
  debug="false";
};

SchemaRegistry-Props セクションを authentication.realm 構成設定に割り当てます。

authentication.realm=SchemaRegistry-Props

上の jaas_config.conf の例では、Jetty PropertyFileLoginModule を使用して、パスワードファイル内の認証情報を確認することでユーザーを認証しています。

データベースから認証情報を読み取るために、LdapLoginModule や JDBCLoginModule など、Java の標準 LoginModule インターフェイスの他の実装を使用することもできます。

file パラメーターは、パスワードファイルの場所です。フォーマットは以下のとおりです。

<username>: <password-hash>,<role1>[,<role2>,...]

以下に例を示します。

fred: OBF:1w8t1tvf1w261w8v1w1c1tvn1w8x,user,admin
barney: changeme,user,developer
betty: MD5:164c88b302622e17050af52c89945d44,user
wilma: CRYPT:adpexzg3FUZAk,admin,sr-user

org.eclipse.jetty.util.security.Password ユーティリティを使用して、ユーザーのパスワードハッシュを取得します。

bin/schema-registry-run-class org.eclipse.jetty.util.security.Password fred letmein

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

letmein
OBF:1w8t1tvf1w261w8v1w1c1tvn1w8x
MD5:0d107d09f5bbe40cade3de5c71e9e9b7
CRYPT:frd5btY/mvXo6

出力の各行は、プレーンテキストから始まり、さまざまなメカニズムを使用してパスワードを暗号化したものです。

基本認証が使用されるように Schema Registry を構成したら、適切かつ有効な資格情報を使用してクライアントを構成する必要があります。次に例を示します。

basic.auth.credentials.source=USER_INFO
basic.auth.user.info=fred:letmein

ちなみに

これらのプロパティの schema.registry プレフィックス付きバージョンは、Confluent Platform 5.0 で非推奨になりました。

  • schema.registry.basic.auth.credentials.source は非推奨となっています。
  • schema.registry.basic.auth.user.info は非推奨となっています。

ガバナンス

Confluent Schema Registry によるデータガバナンスを行うには、次の手順に従います。

  1. スキーマの自動登録を無効にします。
  2. _schemas トピックへのアクセスを制限します。
  3. Schema Registry の操作へのアクセスを制限します。

スキーマの自動登録の無効化

クライアントアプリケーションは、デフォルトで新しいスキーマを自動的に登録します。新しいトピックに新しいメッセージを生成する場合、新しいスキーマを自動的に登録しようと試みます。これは開発環境では非常に便利ですが、本稼働環境では、クライアントアプリケーションで新しいスキーマを自動的に登録することはお勧めしません。クライアントアプリケーションの外部でスキーマを登録し、スキーマがいつ Schema Registry に登録され、どのように進化するかを制御することがベストプラクティスです。

アプリケーション内でスキーマの自動登録を無効にするには、次の例のように構成パラメーター auto.register.schemas=false を設定します。

props.put(AbstractKafkaAvroSerDeConfig.AUTO_REGISTER_SCHEMAS, false);

ちなみに

  • use.latest.version を有効にする場合は、auto.register.schemas を false に設定してスキーマの自動登録を無効にしたうえで、use.latest.version を true に設定する必要があります（デフォルトとは逆の設定）。use.latest.version を正しく機能させるには、オプション auto.register.schemas を false に設定する必要があります。

    auto.register.schemas を false に設定すると、イベントタイプの自動登録が無効になるので、サブジェクト内の最新のスキーマがオーバーライドされることはありません。use.latest.version が true に設定されている場合、シリアライザーは、サブジェクトから最新のスキーマバージョンを検索し、それをシリアル化に使用します。use.latest.version が false（デフォルト）に設定されている場合、シリアライザーは、サブジェクトからイベントタイプを探しますが、その検出に失敗します。

  • Kafka Connect の Schema Registry の「構成オプション」も参照してください。

  • 構成オプション auto.register.schemas は Confluent Platform の機能であり、Apache Kafka® では利用できません。

いったんクライアントアプリケーションでスキーマの自動登録を無効にすると、アプリケーション内から新しいスキーマを動的に登録することはできなくなります。ただしその場合でも、適切な認可が得られれば、Schema Registry から既存のスキーマを取得することはできます。

スキーマトピックへのアクセスの認可

Kafka 認可 を有効にする場合、 特定のリソースに対して次の操作 を行う権限を、Schema Registry のサービスプリンシパルに付与する必要があります。

  • 内部 _schemas トピックへの Read アクセスと Write アクセスです。これで、トピックへの変更を、認可されたユーザーに限定して許可することができます。
  • スキーマトピックに対する DescribeConfigs です。トピックが存在することを確認する際に使用します。
  • スキーマトピックに対する describe topic です。スキーマトピックを一覧表示する権限を、Schema Registry のサービスプリンシパルに付与します。
  • コンシューマーの内部オフセットトピックに対する DescribeConfigs
  • Schema Registry クラスター（group）へのアクセス
  • Kafka クラスターに対する Create アクセス許可
export KAFKA_OPTS="-Djava.security.auth.login.config=<path to JAAS conf file>"

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --producer --consumer --topic _schemas --group schema-registry

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation DescribeConfigs --topic _schemas

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation Describe --topic _schemas

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation Read --topic _schemas

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation Write --topic _schemas

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation Describe --topic __consumer_offsets

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation Create --cluster kafka-cluster

Schema Registry ACL オーソライザー を使用している場合、内部 _schemas_acl トピックに対する Read、Write、DescribeConfigs のアクセス許可も必要となります。

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --producer --consumer --topic _schemas_acl --group schema-registry

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation Read --topic _schemas_acl

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation Write --topic _schemas_acl

bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
               --allow-principal 'User:<sr-principal>' --allow-host '*' \
               --operation DescribeConfigs --topic _schemas_acl

ちなみに

  • Schema Registry のクラスター ID として機能するグループのデフォルトは schema-registry です。カスタマイズするには、schema-registry-group-id の値を指定してください。
  • スキーマを保持する内部トピックのデフォルトのトピック名は _schemas です。カスタマイズするには、kafkastore.topic の値を指定してください。
  • ACL スキーマを保持する内部トピックのデフォルトのトピック名は _schemas_acl （または {{kafkastore.topic}}_acls）です。カスタマイズするには、confluent.schema.registry.acl.topic の値を指定してください。

注釈

  • ワールドレベルのアクセス許可の削除 : 以前のバージョンの Schema Registry では、_schemas トピックを誰でも読み取りおよび書き込み可能とすることが推奨されていました。現在の Schema Registry は SASL をサポートするため、ワールドレベルのアクセス許可は破棄することができます。

セキュリティプラグインを使用した Schema Registry 操作の認可

Schema Registry セキュリティプラグイン は、Schema Registry の各種操作に対する認可を提供します。セキュリティプラグインが着信リクエストを認証し、構成済みのオーソライザーを介してそれらを認可します。これによって、スキーマ進化の管理を、管理ユーザーに限定し、アプリケーションのユーザーには読み取り専用アクセスのみを許可することができます。

おすすめの関連情報