Apicurio Registry 2.4 リリースノート
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 スキーマを登録する場合に、登録前にコンテンツを縮小できるようになりました。
-
Basic 認証用クライアント認証情報フローのスコープの設定: Apicurio Registry は、Basic 認証を使用する場合、ユーザーの代わりにアクセストークンを要求するためにクライアント認証情報フローを使用します。この機能により、ユーザーは
- コミュニティーのみ: カスタムアーティファクトタイプ
独自のカスタムアーティファクトタイプを使用して Apicurio Registry を拡張したり、既存のタイプのサポートを削除したりできる可能性があります。この機能は、Apicurio Registry のコミュニティーバージョンでのみ利用可能であり、サポートされていません。
注記この機能を提供するために、REST API の
ArtifactType
がenum
から単純なstring
に変更されました。カスタム統合に REST API クライアントを使用する場合は、新しいクライアントにアップグレードした後にコードの編集が必要になる場合があります。
Apicurio Registry Operator の新機能
- HTTPS のOperator サポート
-
OpenShift クラスター内での HTTPS 接続の設定のサポートが追加されました。証明書と秘密鍵を含むシークレットをそれぞれ
tls.crt
とtls.key
という名前で作成し、ApicurioRegistry
カスタムリソース定義 (CRD) ファイルのspec.configuration.security.https.secretName
フィールドを設定することでシークレットを参照できます。その後、Apicurio Registry Operator は、Apicurio RegistryService
リソースに HTTPS ポートを設定できます。HTTPS が有効な場合は、spec.security.https.disableHttp
をtrue
に設定することで 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 以外のコンポーネントおよびライブラリーを除く) のログレベルを設定します。OperatorDeployment
リソースでLOG_LEVEL
環境変数を設定することで、Apicurio Registry Operator のログレベルを設定できるようになりました。有効なLOG_LEVEL
値は、debug
、info
、warn
、および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
フィールドは、OpenShiftDeployment
リソースのspec.template
フィールドと構造 (PodTemplateSpec
構造体) が同じです。いくつかの制限がありますが、Apicurio Registry Operator は、このフィールドのデータを Apicurio RegistryDeployment
リソースの、対応するフィールドに転送します。この機能により、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 がインストールされている。
手順
- OpenShift Container Platform Web コンソールで、Administration をクリックしてから Cluster Settings をクリックします。
-
Channel フィールドの横にある鉛筆アイコンをクリックし、次のマイナー
candidate
バージョンを選択します (たとえば、stable-4.9
からcandidate-4.10
に変更します)。 - Save をクリックしてから Update をクリックし、アップグレードが完了するまで待ちます。
-
OpenShift のバージョンが 4.11 未満の場合は、手順 2 と 3 を繰り返し、
candidate-4.11
以降を選択します。 - Operators > Installed Operators > Red Hat Integration - Service Registry をクリックします。
-
Update channel が
2.x
に設定されていることを確認します。 -
Update approval が Automatic に設定されている場合は、
2.x
チャネルが設定された直後にアップグレードを承認してインストールする必要があります。 - Update approval が Manual に設定されている場合は、Install をクリックします。
- Operator がデプロイされ、Apicurio Registry Pod がデプロイされるまで待ちます。
- Apicurio Registry システムが稼働中であることを確認します。
関連情報
- OpenShift Container Platform Web コンソールで Operator 更新チャネルを設定する方法の詳細は、Operator の更新チャネルの変更 を参照してください。
1.5.3. OpenShift 上の Apicurio Registry 1.1 からの移行
Apicurio Registry 1.1 から Apicurio Registry 2.x への移行の詳細は、Apicurio Registry デプロイメントの Red Hat ビルドの移行 を参照してください。
1.6. Apicurio Registry の解決済みの問題
問題 | 説明 |
---|---|
SerDes で Apache Avro の複合型を処理します。 | |
Python SDK で、スネークケース以外のクエリーパラメーターを正しく処理します。 | |
動的 Basic 認証の Web コンソール解決を修正します。 | |
レジストリーは古い Keycloak コンテキストパスを使用しています。 |
問題 | 説明 |
---|---|
Web コンソールで 匿名読み取りアクセス と アーティファクト所有者のみの認証 を有効にすると、エラーが発生して失敗します。 | |
SSL を使用するように KafkaSQL ストレージを設定する場合、キーのパスワードはオプションではありません。 | |
JSON スキーマの互換性チェックが | |
Apicurio Registry をデプロイするときに | |
| |
| |
| |
空のスキーマが提供された場合、互換性チェックでは例外が出力されません。 | |
スキーマのデフォルト値が | |
内部データベースの準備ができる前に、Kafka コンシューマースレッドが開始されます。 | |
リダイレクトフィルターが正しく設定されていません。 | |
互換性ルールはバージョン番号順ではありません。 | |
SASL が有効になっていないと、SSL 設定は機能しません。 | |
registry.ccompat.use-canonical-hash 設定により、保存時にスキーマが正規化された形式に変更されます。 | |
間違った認証情報が認証サーバーに渡された場合、例外は出力されません。 | |
新しいバージョンの Protobuf スキーマのアップロードが | |
REST API を使用してアーティファクトを作成するときに、名前と説明が正しく入力されません。 | |
最新バージョンが無効になっている場合は、スキーマの最新の有効バージョンを取得できません。 | |
複雑な配列オブジェクトの JSON スキーマ検証が失敗します。 |
Apicurio Registry Operator で解決された問題
問題 | 説明 |
---|---|
CORS_ALLOWED_ORIGINS は、作成される OpenShift Pod の環境変数として伝播されません。 |
問題 | 説明 |
---|---|
Operator が作成したサービスにポート名が提供されていません。 | |
デプロイメントが破棄された後に環境変数が欠落しています。 | |
環境変数の管理方法が間違って文書化されています。 | |
ログレベルが正しく設定されていません。 |
1.7. Apicurio Registry が解決した CVE
Apicurio Registry 2.4 で解決された Common Vulnerabilities and Exposures (CVE) は次のとおりです。
問題 | 説明 |
---|---|
CVE-2023-44487 の概要: HTTP/2: 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (ラピッドリセット攻撃) からの影響を受けます。 | |
CVE-2023-44487 netty-codec-http2: HTTP/2: 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (ラピッドリセット攻撃) からの影響を受けます。 | |
CVE-2023-39325 CVE-2023-44487 integration-service-registry-operator-container: さまざまな欠陥。 |
問題 | 説明 |
---|---|
CVE-2022-1471 snakeyaml: Constructor Deserialization Remote Code Execution |
問題 | 説明 |
---|---|
CVE-2023-2976 guava: セキュアでない一時ディレクトリーの作成。 | |
CVE-2021-46877 jackson-databind: JDK シリアル化を使用して JsonNode をシリアル化する場合、DoS の影響を受ける可能性があります。 | |
CVE-2022-3510 protobuf-java: メッセージタイプ拡張機能の解析の問題により DoS が発生します。 | |
CVE-2022-3509 protobuf-java: Textformat 解析の問題が原因で DoS が発生します。 | |
CVE-2023-28867graphql-java: 細工された GraphQL クエリーによりスタック消費が発生します。 | |
CVE-2022-25881 http-cache-semantics: 正規表現のサービス拒否 (ReDoS) の脆弱性。 | |
CVE-2022-3782 keycloak: 二重 URL エンコーディングによるパストラバーサル。 | |
CVE-2022-45787 apache-james-mime4j: MIME4J TempFileStorageProvider での一時ファイル情報の漏洩。 | |
CVE-2022-4742 json-pointer: json-pointer のプロトタイプテイント。 | |
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 の日付形式のバグを次のように修正します。
-
2.x クライアントの依存関係の更新 の説明に従って、すべてのクライアントアプリケーションをバージョン
2.4.4.SP1-redhat-00001
に更新します。 次の環境変数を、以下に示されている値に設定します。
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 カスタマーポータルでアカウントにアクセスします。
アカウントへのアクセス
- access.redhat.com に移動します。
- アカウントがない場合は作成します。
- アカウントにログインします。
サブスクリプションのアクティベート
- access.redhat.com に移動します。
- My Subscriptions に移動します。
- Activate a subscription に移動し、16 桁のアクティベーション番号を入力します。
ZIP および TAR ファイルのダウンロード
ZIP または TAR ファイルにアクセスするには、カスタマーポータルを使用して、ダウンロードする関連ファイルを検索します。RPM パッケージを使用している場合、この手順は必要ありません。
- ブラウザーを開き、access.redhat.com/downloads で Red Hat カスタマーポータルの Product Downloads ページにログインします。
- Integration and Automation カテゴリーで Red Hat Integration エントリーを見つけます。
- 目的の Apicurio Registry 製品を選択します。Software Downloads ページが開きます。
- コンポーネントの Download リンクをクリックします。
改訂日時: 2023-11-07