Apicurio Registry 2.4 リリースノート


Red Hat build of Apicurio Registry 2.4

Red Hat build of Apicurio Registry の新機能

Red Hat build of Apicurio Registry Documentation Team

概要

Red Hat build of Apicurio Registry 製品について説明し、このリリースの新機能に関する最新の詳細を提供します。

はじめに

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。

第1章 Apicurio Registry リリースノート

Apicurio Registry 2.4 の Red Hat ビルドは、一般提供リリースとして提供されます。Apicurio Registry は、Apicurio Registry オープンソースコミュニティープロジェクトをベースとする標準イベントスキーマおよび API デザインのデータストアです。

注記

Red Hat build of Apicurio Registry は、Red Hat Integration Service Registry の新しい製品名です。Red Hat build of Apicurio Registry 2.x と Red Hat Integration Service Registry 2.x は機能的に同じです。

Apicurio Registry を使用して、Web コンソール、REST API、Maven プラグイン、または Java クライアントを使用してデータの構造を管理および共有できます。たとえば、クライアントアプリケーションは、再デプロイせずに最新のスキーマ更新を Apicurio Registry に動的にプッシュまたはプルできます。オプションのルールを作成して、Apicurio Registry のコンテンツが時間とともにどのように進化するかを管理することもできます。このルールには、コンテンツの検証、アーティファクト参照の整合性、スキーマまたは API バージョンの下位互換性または上位互換性が含まれます。

1.1. Apicurio Registry のインストールオプション

次のデータストレージオプションのいずれかを使用して、OpenShift に Apicurio Registry をインストールできます。

  • PostgreSQL データベース
  • Red Hat AMQ Streams

詳細は、OpenShift への Red Hat build of Apicurio Registry のインストールとデプロイ を参照してください。

1.2. Apicurio Registry がサポートするプラットフォーム

Apicurio Registry 2.4 は、次のコアプラットフォームをサポートしています。

  • Red Hat OpenShift Container Platform 4.14、4.13、4.12、4.11
  • Red Hat OpenShift Service on AWS
  • Microsoft Azure Red Hat OpenShift
  • PostgreSQL 15、14、13、12
  • Red Hat AMQ Streams 2.5、2.2
  • OpenJDK 17、11

詳細は、次の記事を参照してください。

1.2.1. 他の製品とのインテグレーションをサポート

Apicurio Registry 2.4 は、次の製品との統合もサポートしています。

  • Red Hat Single Sign-On (RH-SSO) 7.6
  • Red Hat build of Debezium 2.1

1.2.2. Operator メタデータのバージョン

Apicurio Registry のインストールとデプロイに使用される Service Registry Operator メタデータの対応バージョンの詳細は、次の記事を参照してください。

1.3. Apicurio Registry の新機能

Apicurio Registry 2.4 には、次の新機能が含まれています。

Apicurio Registry コアの新機能
アーティファクト参照の改善
  • アーティファクト参照整合性ルール: 新しいアーティファクト固有のルールとグローバルルールを適用して、アーティファクトの作成または更新時にアーティファクト参照の整合性を強制的に確保できるようになりました。すべてのアーティファクトタイプについて、ルールは重複したアーティファクト参照を検出し、存在しないアーティファクトへの参照を防ぎます。アーティファクトタイプのサブセット (Apache Avro、Google Protobuf、OpenAPI、および AsyncAPI) の場合、ルールにより、すべてのアーティファクト参照がマッピングされることが保証されます。
  • Maven プラグインでのアーティファクト参照の自動検出: アーティファクトタイプのサブセット (Apache Avro、Google Protobuf、および JSON スキーマ) について、アーティファクト作成時または更新時に、特定のアーティファクトのすべてのアーティファクト参照を Maven プラグインで自動的に識別して設定できるようになりました。
  • Web コンソールでのアーティファクト参照の視覚化: 新しい References タブで、アーティファクトバージョンの受信参照と送信参照の両方を表示できるようになりました。REST API は、受信参照と送信参照の両方の取得をサポートするようになりました。以前は、REST API は送信参照のみを取得し、Web コンソールには参照が表示されませんでした。
  • アーティファクト参照をコンテンツとして処理: このリリースで、コンテンツハッシュと ID を計算するとき、およびアーティファクトバージョンの互換性をチェックするときに、アーティファクト参照が考慮されるようになりました。同じスキーマコンテンツを異なる参照とともにアップロードすると、新しいアーティファクトバージョンが作成されます。
OpenAPI のクライアント SDK 生成
このリリースでは、ユーザーが OpenAPI アーティファクトからクライアント SDK を生成できるようにする新しい Web コンソール機能が追加されています。この機能は、Microsoft の Kiota を使用して SDK を生成します。この機能はブラウザー内でのみ実行され、API を使用して自動化できません。詳細は、https://github.com/microsoft/kiota を参照してください。
アーティファクトのバージョンの削除
このリリースでは、Web コンソールに新しい REST API 操作と新しい アーティファクトバージョンの削除 設定が追加され、REST API を使用してアーティファクトバージョンを削除できるようになります。以前のリリースでは、アーティファクトのバージョンは不変で、非推奨にしたり無効にしたりすることはできますが、削除できませんでした。ただし、このような意味合いがありますが、アーティファクトのバージョンを削除する必要がある場合があります。たとえば、規制またはポリシー上の理由により、アーティファクトのバージョンを削除する必要がある場合があります。
Core Registry REST API の改善
  • バージョンコメント API: REST API を使用して、アーティファクトバージョンにコメントを追加できるようになりました。コメントの管理は、Web コンソールではまだ利用できません。
  • エクスポート API が Accept ヘッダーで application/json をサポート: /admin/export API エンドポイントへの呼び出しで、Accept ヘッダーの値として application/json を送信できるようになりました。以前のリリースでは、application/json 形式の応答を返す唯一の方法は、forBrowser クエリーパラメーターを使用することでした。これで、クエリーパラメーターまたは Accept ヘッダーのいずれかを使用できるようになります。
  • グループ管理: アーティファクト作成の一環としてアーティファクトグループを暗黙的に管理するのではなく、必要に応じて、REST API を使用してグループを直接管理できるようになりました。
Confluent との互換性がある REST API の改善
  • Confluent との互換性がある API のサポートを更新: Confluent Schema Registry API のバージョン 7 のサポートを追加しました。Apicurio Registry は、異なるエンドポイントで v6 と v7 の両方をサポートするようになりました。
  • カスタマイズ可能なサブジェクトの最大数: registry.ccompat.max-subjects 動的設定プロパティーを使用して、ccompat API によって返されるサブジェクトの最大数をカスタマイズできるようになりました。
  • グループカスタマイズへのヘッダーの追加: Confluent Schema Registry API v7 を使用する場合、X-Registry-GroupId ヘッダーを使用してアーティファクトグループを指定できるようになりました。このヘッダーを使用しない場合、すべてのアーティファクトがデフォルトグループに配置されていると見なされます。
Microsoft Azure Active Directory での認証のサポート
Core Registry REST API および Web コンソールにアクセスするために、Microsoft Azure で Active Directory 認証を使用する場合のサポートが追加されました。詳細は、Apicurio のブログ記事 Securing Apicurio Registry 2.4.x using Azure Active Directory を参照してください。
HTTPS パススルー Ingress のサポート

HTTPS パススルー Ingress を使用して Apicurio Registry をデプロイする際に、リダイレクトの問題を回避する設定変数を提供します。

  • REGISTRY_URL_OVERRIDE_HOST - 外部からアクセス可能な URL を生成するために使用されるホスト名をオーバーライドします。
  • REGISTRY_URL_OVERRIDE_PORT - 外部からアクセス可能な URL を生成するために使用されるポートをオーバーライドします。

    これらのホストおよびポートのオーバーライドは、HTTPS パススルーの Ingress またはルートを使用して Apicurio Registry をデプロイする場合に役立ちます。このような場合、リダイレクトに再利用されるリクエスト URL およびポートは、リクエストがプロキシーされるため、クライアントが使用する実際の外部 URL に属しません。ターゲット URL に到達できないため、リダイレクトは失敗します。

その他の変更点
  • Basic 認証用クライアント認証情報フローのスコープの設定: Apicurio Registry は、Basic 認証を使用する場合、ユーザーの代わりにアクセストークンを要求するためにクライアント認証情報フローを使用します。この機能により、ユーザーは scope 要求パラメーターを設定できます。
  • コンテンツハッシュを使用したシリアライザー/デシリアライザーアーティファクトの解決: SerDe クラスは、スキーマのコンテンツハッシュを使用してアーティファクトの座標を解決できるようになりました。
  • Avro を縮小するための Maven プラグインオプション: Maven プラグインを使用して Avro スキーマを登録する場合に、登録前にコンテンツを縮小できるようになりました。
コミュニティーのみ: カスタムアーティファクトタイプ

独自のカスタムアーティファクトタイプを使用して Apicurio Registry を拡張したり、既存のタイプのサポートを削除したりできる可能性があります。この機能は、Apicurio Registry のコミュニティーバージョンでのみ利用可能であり、サポートされていません。

注記

この機能を提供するために、REST API の ArtifactTypeenum から単純な string に変更されました。カスタム統合に REST API クライアントを使用する場合は、新しいクライアントにアップグレードした後にコードの編集が必要になる場合があります。

Apicurio Registry Operator の新機能
HTTPS のOperator サポート
OpenShift クラスター内での HTTPS 接続の設定のサポートが追加されました。証明書と秘密鍵を含むシークレットをそれぞれ tls.crttls.key という名前で作成し、ApicurioRegistry カスタムリソース定義 (CRD) ファイルの spec.configuration.security.https.secretName フィールドを設定することでシークレットを参照できます。その後、Apicurio Registry Operator は、Apicurio Registry Service リソースに HTTPS ポートを設定できます。HTTPS が有効な場合は、spec.security.https.disableHttptrue に設定することで HTTP 接続を無効にできます。
手動で管理される OpenShift リソースのサポート

特定のリソースタイプを無効にして、Apicurio Registry Operator がそれらのリソースを作成または管理しないようにし、リソースを手動で設定できるようになります。手動設定を使用すると、Apicurio Registry Operator が現在サポートしていない機能をより柔軟に使用できます。リソースタイプを無効にすると、その既存のインスタンスは削除されます。リソースタイプを有効にすると、Apicurio Registry Operator は、アプリラベル (例: app=example-apicurioregistry) を使用してリソースを検索し、その管理を開始しようとします。それ以外の場合、Apicurio Registry Operator は新しいインスタンスを作成します。この方法で、次のリソースタイプを無効にすることができます。

  • Ingress
  • NetworkPolicy
  • PodDisruptionBudget
ログレベル設定の改善
ApicurioRegistry CRD ファイルの spec.configuration.registryLogLevel フィールドを使用して、Apicurio Registry と Apicurio Registry Operator のログレベルをより簡単に設定できるようになりました。この新しいフィールドは、Apicurio 以外のコンポーネントおよびライブラリーに機能する spec.configuration.logLevel フィールドとは対照的に、Apicurio アプリケーションコンポーネント (Apicurio 以外のコンポーネントおよびライブラリーを除く) のログレベルを設定します。Operator Deployment リソースで LOG_LEVEL 環境変数を設定することで、Apicurio Registry Operator のログレベルを設定できるようになりました。有効な LOG_LEVEL 値は、debuginfowarn、および error です。
CORS で許可される送信元

サーバーは、Cross-Origin Resource Sharing (CORS) メカニズムを使用して、応答を要求の送信元と共有できるかどうかを制御できます。Apicurio Registry Operator は、ApicurioRegistry CRD ファイルの spec.deployment.host および spec.configuration.security.keycloak.url フィールドの値に基づいて、CORS_ALLOWED_ORIGINS 環境変数を設定するようになりました。この環境変数は、Apicurio Registry によって送信される Access-Control-Allow-Origin ヘッダーを制御します。

カスタム Ingress を使用する場合 (たとえば、HTTPS を設定するため)、spec.deployment.managedResources.disableIngress フィールドを true に設定することで Operator 管理の Ingress を無効にし、それでも spec.deployment.host フィールドを適切な値に設定できます。完全にカスタマイズされた CORS ポリシーを設定する場合は、spec.deployment.env フィールドを使用して CORS_ALLOWED_ORIGINS 環境変数を手動で設定できます。

Pod テンプレートを使用した Apicurio Registry デプロイメントの設定

ApicurioRegistry CRD ファイルには、テクノロジープレビュー機能として spec.deployment.podTemplateSpecPreview フィールドが含まれるようになりました。spec.deployment.podTemplateSpecPreview フィールドは、OpenShift Deployment リソースの spec.template フィールドと構造 (PodTemplateSpec 構造体) が同じです。いくつかの制限がありますが、Apicurio Registry Operator は、このフィールドのデータを Apicurio Registry Deployment リソースの、対応するフィールドに転送します。この機能により、Apicurio Registry Operator が各ユースケースをネイティブにサポートする必要がなく、設定の柔軟性が向上します。

重要

テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能では、最新の製品機能をいち早く提供します。これにより、お客様は開発段階で機能をテストし、フィードバックを提供できます。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Apicurio Registry ユーザーのドキュメントおよび例

ドキュメントライブラリーは、バージョン 2.4 で利用可能な新機能で更新されました。

オープンソースのデモンストレーションアプリケーションも更新されました。

1.4. Apicurio Registry の非推奨機能

Apicurio Registry コアの非推奨機能
  • Confluent Schema Registry API バージョン 6 (互換性 API): Apicurio Registry は現在、別のエンドポイントで Confluent Schema Registry API の 2 つのバージョン (バージョン 6 とバージョン 7) をサポートしています。バージョン 6 の使用は非推奨です。v6 API エンドポイントは今後のリリースで削除される予定です。v6 エンドポイントへのすべての参照を v7 API エンドポイントへの参照に置き換えてください。
  • Apicurio Registry Core API バージョン 1: Apicurio Registry Core API (バージョン 1) の元のバージョンに対する Apicurio Registry のサポートは廃止されました。従来の API は次のメジャーリリースで削除される予定です。
  • 動的ログレベル設定: /admin/loggers および /admin/loggers/{logger} API エンドポイントは、Apicurio Registry Core API (v2) で非推奨になりました。これらのエンドポイントは今後のリリースで削除される予定です。
  • Registry V1 エクスポートユーティリティー: Apicurio コマンドラインエクスポートユーティリティーのレジストリーサポートは廃止されました。Apicurio Registry 1.x から 2.x にインポートできる形式にデータをエクスポートするためのエクスポートツールに対する、リリースおよびメンテナンスがなくなりました。すべてのお客様はすでに 1.x から 2.x にアップグレードしているはずです。
Apicurio Registry Operator の非推奨機能
  • Deployment リソースの編集による環境変数の設定: 以前のバージョンでは、Apicurio Registry Operator によってサポートされていた Deployment リソースを直接編集することで、Apicurio Registry の環境変数を設定できました。ApicurioRegistry CRD ファイルの spec.configuration.env フィールドを使用して環境変数を管理できるようになったため、以前の手順は非推奨となり、それに対する Operator サポートは削除されます。Operator によって設定されていないすべての環境変数を設定するには、必ず spec.configuration.env フィールドを使用してください。
  • 有効になっていない機能の環境変数の保持: Apicurio Registry Operator は、KafkaSQL ストレージ使用時の Salted Challenge Response Authentication Mechanism (SCRAM) セキュリティーなど、さまざまな機能を有効にして設定するための環境変数を設定します。このような機能が無効になっている場合、Operator は現在、関連する環境変数を保持しているため、問題が発生する可能性があります。このような環境変数の保持は非推奨となり、それに対する Operator のサポートは削除されます。このような環境変数に依存するデプロイメントは使用しないようにしてください。
  • 環境変数の優先順位: Apicurio Registry Operator は、spec.configuration.env フィールドですでに明示的に指定されている環境変数を設定しようとする場合があります。環境変数に競合する値がある場合、デフォルトでは、Apicurio Registry Operator によって設定された値が優先されます。この動作は今後変更され、Operator によって設定されたほとんどの環境変数をユーザーが上書きできるようになります。デプロイメントが元の優先動作に依存していないことを確認してください。

1.5. Apicurio Registry デプロイメントのアップグレードと移行

OpenShift では、Apicurio Registry サーバーを Apicurio Registry 2.x から Apicurio Registry 2.4 に自動的にアップグレードできます。Apicurio Registry 1.x から Apicurio Registry 2.x への自動アップグレードはなく、移行プロセスが必要です。

1.5.1. 2.x クライアントの依存関係の更新

このリリースではクライアントの依存関係を更新することは必須ではありません。既存の 2.x クライアントは引き続き Apicurio Registry 2.4 で動作します。

ただし、Apicurio Registry の次のリリースの前に、最新の Apicurio Registry クライアントバージョンを使用するようにクライアントアプリケーションの依存関係をすべて更新する必要があります。クライアントアプリケーションの依存関係には、Kafka シリアライザー/デシリアライザー (SerDes)、Maven プラグイン、および Java REST クライアントの依存関係が含まれます。たとえば、Java REST クライアントの Maven 依存関係を更新するには、次のように pom.xml ファイルでバージョンを指定します。

<dependency>
    <groupId>io.apicurio</groupId>
    <artifactId>apicurio-registry-client</artifactId>
    <version>2.4.4.SP1-redhat-00001</version>
</dependency>

詳細は、デフォルトで有効になっているレガシー REST API の日付形式 を参照してください。

1.5.2. OpenShift での Apicurio Registry 2.x からのアップグレード

OpenShift 4.9 の Apicurio Registry 2.x から OpenShift 4.10 以降の Apicurio Registry 2.4 にアップグレードできます。Apicurio Registry と OpenShift の両方のバージョンをアップグレードし、OpenShift のマイナーバージョンを 1 つずつアップグレードする必要があります。

前提条件

  • すでに OpenShift 4.9 に Apicurio Registry 2.x がインストールされている。

手順

  1. OpenShift Container Platform Web コンソールで、Administration をクリックしてから Cluster Settings をクリックします。
  2. Channel フィールドの横にある鉛筆アイコンをクリックし、次のマイナー candidate バージョンを選択します (たとえば、stable-4.9 から candidate-4.10 に変更します)。
  3. Save をクリックしてから Update をクリックし、アップグレードが完了するまで待ちます。
  4. OpenShift のバージョンが 4.11 未満の場合は、手順 2 と 3 を繰り返し、candidate-4.11 以降を選択します。
  5. Operators > Installed Operators > Red Hat Integration - Service Registry をクリックします。
  6. Update channel2.x に設定されていることを確認します。
  7. Update approvalAutomatic に設定されている場合は、2.x チャネルが設定された直後にアップグレードを承認してインストールする必要があります。
  8. Update approvalManual に設定されている場合は、Install をクリックします。
  9. Operator がデプロイされ、Apicurio Registry Pod がデプロイされるまで待ちます。
  10. Apicurio Registry システムが稼働中であることを確認します。

関連情報

1.5.3. OpenShift 上の Apicurio Registry 1.1 からの移行

Apicurio Registry 1.1 から Apicurio Registry 2.x への移行の詳細は、Apicurio Registry デプロイメントの Red Hat ビルドの移行 を参照してください。

1.6. Apicurio Registry の解決済みの問題

表1.1 Apicurio Registry で解決されたバージョン 2.4.4 の問題
問題説明

Registry-3496

SerDes で Apache Avro の複合型を処理します。

Registry-3466

Python SDK で、スネークケース以外のクエリーパラメーターを正しく処理します。

Registry-3458

動的 Basic 認証の Web コンソール解決を修正します。

Registry-3315

レジストリーは古い Keycloak コンテキストパスを使用しています。

表1.2 Apicurio Registry で解決されたバージョン 2.4.3 の問題
問題説明

Registry-3307

Web コンソールで 匿名読み取りアクセスアーティファクト所有者のみの認証 を有効にすると、エラーが発生して失敗します。

Registry-3260

SSL を使用するように KafkaSQL ストレージを設定する場合、キーのパスワードはオプションではありません。

Registry-3184

JSON スキーマの互換性チェックが multipleOf 比較で失敗します。

Registry-3143

Apicurio Registry をデプロイするときに DownloadReaper エラーが発生します。

Registry-3096

SearchedGroup.createdBy プロパティーの型は Object ではなく String である必要があります。

Registry-3088

enum アーティファクト参照とレコード ID 戦略におけるシリアル化エラーが発生します。

Registry-3086

$ref を使用して他のスキーマを参照する JSON スキーマをアップロードできません。

Registry-3080

空のスキーマが提供された場合、互換性チェックでは例外が出力されません。

Registry-3014

スキーマのデフォルト値が {} の場合、アップロードは 422 エラーで失敗します。

Registry-2991

内部データベースの準備ができる前に、Kafka コンシューマースレッドが開始されます。

Registry-2955

リダイレクトフィルターが正しく設定されていません。

Registry-2952

互換性ルールはバージョン番号順ではありません。

Registry-2938

SASL が有効になっていないと、SSL 設定は機能しません。

Registry-2902

registry.ccompat.use-canonical-hash 設定により、保存時にスキーマが正規化された形式に変更されます。

Registry-2880

間違った認証情報が認証サーバーに渡された場合、例外は出力されません。

Registry-2877

新しいバージョンの Protobuf スキーマのアップロードが NullPointerException で失敗します。

Registry-2826

REST API を使用してアーティファクトを作成するときに、名前と説明が正しく入力されません。

Registry-2790

最新バージョンが無効になっている場合は、スキーマの最新の有効バージョンを取得できません。

Registry-2552

複雑な配列オブジェクトの JSON スキーマ検証が失敗します。

Apicurio Registry Operator で解決された問題
表1.3 Apicurio Registry Operator のバージョン 2.4.4 で解決された問題
問題説明

IPT-960

CORS_ALLOWED_ORIGINS は、作成される OpenShift Pod の環境変数として伝播されません。

表1.4 Apicurio Registry Operator のバージョン 2.4.3 で解決された問題
問題説明

IPT-916

Operator が作成したサービスにポート名が提供されていません。

IPT-883

デプロイメントが破棄された後に環境変数が欠落しています。

IPT-852

環境変数の管理方法が間違って文書化されています。

Operator-119

ログレベルが正しく設定されていません。

1.7. Apicurio Registry が解決した CVE

Apicurio Registry 2.4 で解決された Common Vulnerabilities and Exposures (CVE) は次のとおりです。

表1.5 Apicurio Registry で解決されたバージョン 2.4.4.SP1 の CVE
問題説明

IPT-1021

CVE-2023-44487 の概要: HTTP/2: 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (ラピッドリセット攻撃) からの影響を受けます。

IPT-1020

CVE-2023-44487 netty-codec-http2: HTTP/2: 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (ラピッドリセット攻撃) からの影響を受けます。

IPT-1019

CVE-2023-39325 CVE-2023-44487 integration-service-registry-operator-container: さまざまな欠陥。

表1.6 Apicurio Registry バージョン 2.4.4 で解決された CVE
問題説明

IPT-959

CVE-2022-1471 snakeyaml: Constructor Deserialization Remote Code Execution

表1.7 Apicurio Registry バージョン 2.4.3 で解決された CVE
問題説明

IPT-943

CVE-2023-2976 guava: セキュアでない一時ディレクトリーの作成。

IPT-890

CVE-2021-46877 jackson-databind: JDK シリアル化を使用して JsonNode をシリアル化する場合、DoS の影響を受ける可能性があります。

IPT-880

CVE-2022-3510 protobuf-java: メッセージタイプ拡張機能の解析の問題により DoS が発生します。

IPT-879

CVE-2022-3509 protobuf-java: Textformat 解析の問題が原因で DoS が発生します。

IPT-876

CVE-2023-28867graphql-java: 細工された GraphQL クエリーによりスタック消費が発生します。

IPT-866

CVE-2022-25881 http-cache-semantics: 正規表現のサービス拒否 (ReDoS) の脆弱性。

IPT-856

CVE-2022-3782 keycloak: 二重 URL エンコーディングによるパストラバーサル。

IPT-850

CVE-2022-45787 apache-james-mime4j: MIME4J TempFileStorageProvider での一時ファイル情報の漏洩。

IPT-845

CVE-2022-4742 json-pointer: json-pointer のプロトタイプテイント。

IPT-825

CVE-2022-40152 woodstox-core: XML データをシリアル化する woodstox は、サービス拒否 (DoS) 攻撃に対して脆弱である。

1.8. Apicurio Registry の既知の問題

次の既知の問題は、Apicurio Registry 2.4.x に適用されます。

Apicurio Registry コアの既知の問題

Registry-3413: レガシー REST API の日付形式がデフォルトで有効。

互換性を最大限に高め、Apicurio Registry の古いバージョンから簡単にアップグレードできるように、OpenAPI 標準に準拠しない日付形式が REST API で使用されています (以前のバージョンのバグが原因)。

次の Apicurio Registry リリースの前に、すべてのクライアントアプリケーションをアップグレードして最新のクライアントバージョンを使用するようにしてください。次のリリースでは日付形式のバグが修正されるため、古いクライアントは REST API と互換性がなくなります。

REST API を OpenAPI 準拠に更新するには、この バージョンの Apicurio Registry の日付形式のバグを次のように修正します。

  1. 2.x クライアントの依存関係の更新 の説明に従って、すべてのクライアントアプリケーションをバージョン 2.4.4.SP1-redhat-00001 に更新します。
  2. 次の環境変数を、以下に示されている値に設定します。

    REGISTRY_APIS_V2_DATE_FORMAT=yyyy-MM-dd'T'HH:mm:ss'Z'

IPT-814: Apicurio Registry のログアウト機能が RH-SSO 7.6 と互換性がない

RH-SSO 7.6 では、ログアウトエンドポイントで使用される redirect_uri パラメーターが非推奨になりました。詳細は、RH-SSO 7.6 アップグレードガイド を参照してください。これは非推奨であるため、RH-SSO Operator を使用して Apicurio Registry のセキュリティー保護を行っている場合は、Logout ボタンをクリックすると、Invalid parameter: redirect_uri エラーが表示されます。

回避策は、https://access.redhat.com/solutions/6980926 を参照してください。

IPT-701: CVE-2022-23221 H2 により、JNDI を介してリモートサーバーからカスタムクラスをロードできる

Apicurio Registry データが AMQ Streams に保存されている場合、H2 データベースコンソールにより、リモート攻撃者は JDBC URL を使用して任意コードを実行できます。Apicurio Registry はデフォルトでは脆弱ではなく、悪意のある設定変更が必要です。

Apicurio Registry Operator の既知の問題

Operator-42: OpenShift ルートの自動生成では、間違ったベースホスト値が使用される可能性がある

複数の routerCanonicalHostname 値が指定されている場合は、Apicurio Registry OpenShift ルートの自動生成で間違ったベースホスト値が使用される可能性があります。

付録A サブスクリプションの使用

Apicurio Registry は、ソフトウェアサブスクリプションから提供されます。サブスクリプションを管理するには、Red Hat カスタマーポータルでアカウントにアクセスします。

アカウントへのアクセス

  1. access.redhat.com に移動します。
  2. アカウントがない場合は作成します。
  3. アカウントにログインします。

サブスクリプションのアクティベート

  1. access.redhat.com に移動します。
  2. My Subscriptions に移動します。
  3. Activate a subscription に移動し、16 桁のアクティベーション番号を入力します。

ZIP および TAR ファイルのダウンロード

ZIP または TAR ファイルにアクセスするには、カスタマーポータルを使用して、ダウンロードする関連ファイルを検索します。RPM パッケージを使用している場合、この手順は必要ありません。

  1. ブラウザーを開き、access.redhat.com/downloads で Red Hat カスタマーポータルの Product Downloads ページにログインします。
  2. Integration and Automation カテゴリーで Red Hat Integration エントリーを見つけます。
  3. 目的の Apicurio Registry 製品を選択します。Software Downloads ページが開きます。
  4. コンポーネントの Download リンクをクリックします。

改訂日時: 2023-11-07

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.