Confluent Cloud スキーマ管理のドキュメントをお探しですか? これらのページでは、Schema Registry の全体的な概念、スキーマフォーマット、ハイブリッドのユースケース、チュートリアル といったポイントに触れていますが、最も重点的に取り上げているのは Confluent Platform です。Confluent Cloud のドキュメントについては、Confluent Cloud でのスキーマの管理」をご覧ください。
Schema Registry のセキュリティの概要¶
機能¶
Confluent Schema Registry は現在、Kafka のセキュリティ機能をすべてサポートしています。以下はその例です。
- 暗号化
- セキュアな Kafka クラスターに対する SSL 暗号化
- HTTPS でのエンドユーザー REST API 呼び出し
- 認証
- セキュアな Kafka クラスターに対する SSL 認証
- セキュアな Kafka クラスターに対する SASL 認証
- ZooKeeper に対する SASL 認証
- Jetty 認証(「ロールベースアクセス制御」の手順を参照)
- 認可(Schema Registry セキュリティプラグイン が必要)
構成の詳細については、 構成オプション を参照してください。
参考
セキュアな 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¶
重要
- ZooKeeper のリーダー選出は非推奨となっています。代わりに Kafka のリーダー選出を使用してください。「実行中クラスターへのセキュリティの追加」の ZooKeeper に関するセクション(特に、Kafka ブローカーと ZooKeeper との間でセキュリティを有効にする方法について説明する ZooKeeper のセクション)もお読みください。
- 以前のバージョンの Confluent Platform (5.4.x 以前)では、
kafkastore.connection.url
(ZooKeeper)と kafkastore.bootstrap.servers (Kafka)の両方が構成されている場合、ZooKeeper がリーダー選出に使用され、トピック ACL オーソライザー Schema Registry プラグインにも必要でした。Schema Registry ACL オーソライザー では、kafkastore.connection.url
はプラグインに不要になりました。
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 構成パラメーターも設定する必要があります。
- 型: list
- デフォルト: "http://0.0.0.0:8081"
- 重要度: 高
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 を使用するようにクライアントを構成するには、次のプロパティまたは環境変数を設定します。
HTTPS のリスナー構成に合わせて、クライアントの
schema.registry.url
を構成します。<client>.schema.registry.url: "<schema-registry-url>:<port>"
クライアントの環境変数の構成で、SSL のキーストアとトラストストアを設定します。次の 2 つの方法のいずれかを使用してください。
(推奨) Schema Registry 専用プロパティを使用してクライアントを構成
schema.registry.ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks schema.registry.ssl.truststore.password=<password> schema.registry.ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks schema.registry.ssl.keystore.password=<password> 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」を参照してください。
(従来)クライアントに応じた環境変数を設定する(
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 によるデータガバナンスを行うには、次の手順に従います。
- スキーマの自動登録を無効にします。
- _schemas トピックへのアクセスを制限します。
- 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 の各種操作に対する認可を提供します。セキュリティプラグインが着信リクエストを認証し、構成済みのオーソライザーを介してそれらを認可します。これによって、スキーマ進化の管理を、管理ユーザーに限定し、アプリケーションのユーザーには読み取り専用アクセスのみを許可することができます。