Red Hat SummitRed Hat Integration 2023.q3 リリースノート
Red Hat Integration の新機能
概要
はじめに
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 Red Hat Integration
Red Hat Integration は、ハイブリッド環境およびマルチクラウド環境全体でコンテナーベースの統合サービスを作成、拡張、デプロイするための包括的な統合およびイベント処理技術です。Red Hat Integration は、デジタル環境で必要となるアプリケーションとシステム間でデータを接続および共有するために組織が使用できる、アジャイルで API 中心の分散ソリューションを提供します。
Red Hat Integration には、以下の機能が含まれています。
- リアルタイムのメッセージング
- データセンター間のメッセージストリーミング
- API の接続
- アプリケーションコネクター
- エンタープライズ統合パターン
- API 管理
- データの変換
- サービスの設定とオーケストレーション
第2章 Service Registry リリースノート
Service Registry 2.4 は、一般公開リリースとして提供されています。Service Registry は、標準イベントスキーマおよび API 設計用のデータストアであり、Apicurio Registry オープンソースコミュニティープロジェクトに基づいています。
Apicurio Registry の Red Hat ビルドが Red Hat Application Foundations の一部として利用できるようになりました。Red Hat build of Apicurio Registry 2.x と Red Hat Integration Service Registry 2.x は機能的に同じです。詳細は、https://access.redhat.com/products/red-hat-application-foundations/ を参照してください。
Service Registry を使用して、Web コンソール、REST API、Maven プラグイン、または Java クライアントを使用してデータの構造を管理および共有できます。たとえば、クライアントアプリケーションは、再デプロイせずに最新のスキーマ更新を Service Registry に動的にプッシュまたはプルできます。また、必要に応じて、Service Registry のコンテンツの経時的な変化を管理するためのルールを作成することもできます。このルールには、コンテンツの検証、アーティファクト参照の整合性、スキーマまたは API バージョンの下位互換性または上位互換性が含まれます。
2.1. Service Registry のインストールオプション
以下のデータストレージオプションのいずれかを使用して、Service Registry を OpenShift にインストールできます。
- PostgreSQL データベース
- Red Hat AMQ Streams
詳細は、OpenShift での Service Registry のインストールおよびデプロイ を参照してください。
2.2. Service Registry がサポートするプラットフォーム
Service 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
詳細は、次の記事を参照してください。
2.2.1. 他の製品とのインテグレーションをサポート
Service Registry 2.4 は、以下の製品との統合もサポートしています。
- Red Hat Single Sign-On (RH-SSO) 7.6
- Red Hat build of Debezium 2.1
2.2.2. Operator メタデータのバージョン
Service Registry のインストールとデプロイに使用される Service Registry Operator メタデータの対応バージョンの詳細は、次の記事を参照してください。
2.3. Service Registry の新機能
Service Registry 2.4 には、次の新機能が含まれています。
Service 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/exportAPI エンドポイントへの呼び出しで、Acceptヘッダーの値としてapplication/jsonを送信できるようになりました。以前のリリースでは、application/json形式の応答を返す唯一の方法は、forBrowserクエリーパラメーターを使用することでした。これで、クエリーパラメーターまたはAcceptヘッダーのいずれかを使用できるようになります。 - グループ管理: アーティファクト作成の一環としてアーティファクトグループを暗黙的に管理するのではなく、必要に応じて、REST API を使用してグループを直接管理できるようになりました。
- Confluent との互換性がある REST API の改善
- Confluent との互換性がある API のサポートを更新: Confluent Schema Registry API のバージョン 7 のサポートを追加しました。Service Registry は、異なるエンドポイントでの v6 と v7 の使用をサポートするようになりました。
-
カスタマイズ可能なサブジェクトの最大数:
registry.ccompat.max-subjects動的設定プロパティーを使用して、ccompatAPI によって返されるサブジェクトの最大数をカスタマイズできるようになりました。 -
グループカスタマイズへのヘッダーの追加: 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 を使用して Service Registry をデプロイする際に、リダイレクトの問題を回避する設定変数を提供します。
-
REGISTRY_URL_OVERRIDE_HOST- 外部からアクセス可能な URL を生成するために使用されるホスト名をオーバーライドします。 REGISTRY_URL_OVERRIDE_PORT- 外部からアクセス可能な URL を生成するために使用されるポートをオーバーライドします。これらのホストおよびポートのオーバーライドは、HTTPS パススルーの Ingress またはルートを使用して Service Registry をデプロイする場合に役立ちます。このような場合、リダイレクトに再利用されるリクエスト URL およびポートは、リクエストがプロキシーされるため、クライアントが使用する実際の外部 URL に属しません。ターゲット URL に到達できないため、リダイレクトは失敗します。
-
- その他の変更点
-
Basic 認証用クライアント認証情報フローのスコープの設定: Service Registry は、Basic 認証を使用する場合、ユーザーの代わりにアクセストークンを要求するためにクライアント認証情報フローを使用します。この機能により、ユーザーは
scope要求パラメーターを設定できます。 -
コンテンツハッシュを使用したシリアライザー/デシリアライザーアーティファクトの解決:
SerDeクラスは、スキーマのコンテンツハッシュを使用してアーティファクトの座標を解決できるようになりました。 - Avro を縮小するための Maven プラグインオプション: Maven プラグインを使用して Avro スキーマを登録する場合に、登録前にコンテンツを縮小できるようになりました。
-
Basic 認証用クライアント認証情報フローのスコープの設定: Service Registry は、Basic 認証を使用する場合、ユーザーの代わりにアクセストークンを要求するためにクライアント認証情報フローを使用します。この機能により、ユーザーは
- コミュニティーのみ: カスタムアーティファクトタイプ
独自のカスタムアーティファクトタイプを使用して Service Registry を拡張したり、既存のタイプのサポートを削除したりできます。この機能は、Service Registry のコミュニティーバージョンでのみ利用可能であり、サポート対象の機能ではありません。
注記この機能を提供するために、REST API の
ArtifactTypeがenumから単純なstringに変更されました。カスタム統合に REST API クライアントを使用する場合は、新しいクライアントにアップグレードした後にコードの編集が必要になる場合があります。
Service Registry Operator の新機能
- HTTPS の Operator サポート
-
OpenShift クラスター内での HTTPS 接続の設定のサポートが追加されました。証明書と秘密鍵を含むシークレットをそれぞれ
tls.crtとtls.keyという名前で作成し、ApicurioRegistryカスタムリソース定義 (CRD) ファイルのspec.configuration.security.https.secretNameフィールドを設定することでシークレットを参照できます。これにより、Service Registry Operator が、Service Registry のServiceリソースに HTTPS ポートを設定できるようになります。HTTPS が有効な場合は、spec.security.https.disableHttpをtrueに設定することで HTTP 接続を無効にできます。 - 手動で管理される OpenShift リソースのサポート
特定のリソースタイプを無効にして、Service Registry Operator によるそのタイプのリソースの作成または管理を終了し、リソースを手動で設定できるようになりました。手動設定を使用すると、Service Registry Operator が現在サポートしていない機能をより柔軟に使用できます。リソースタイプを無効にすると、その既存のインスタンスは削除されます。リソースタイプを有効にすると、Service Registry Operator は、アプリラベル (例:
app=example-apicurioregistry) を使用してリソースを検索し、その管理を開始しようとします。見つからない場合、Service Registry Operator は新しいインスタンスを作成します。この方法で、次のリソースタイプを無効にすることができます。-
Ingress -
NetworkPolicy -
PodDisruptionBudget
-
- ログレベル設定の改善
-
ApicurioRegistryCRD ファイルのspec.configuration.registryLogLevelフィールドを使用して、Service Registry と Service Registry Operator のログレベルをより簡単に設定できるようになりました。この新しいフィールドは、Apicurio 以外のコンポーネントおよびライブラリーに機能するspec.configuration.logLevelフィールドとは対照的に、Apicurio アプリケーションコンポーネント (Apicurio 以外のコンポーネントおよびライブラリーを除く) のログレベルを設定します。Operator のDeploymentリソースでLOG_LEVEL環境変数を設定することで、Service Registry Operator のログレベルを設定できるようになりました。有効なLOG_LEVEL値は、debug、info、warn、およびerrorです。 - CORS で許可される送信元
サーバーは、Cross-Origin Resource Sharing (CORS) メカニズムを使用して、応答を要求の送信元と共有できるかどうかを制御できます。Service Registry Operator は、
ApicurioRegistryCRD ファイルのspec.deployment.hostおよびspec.configuration.security.keycloak.urlフィールドの値に基づいて、CORS_ALLOWED_ORIGINS環境変数を設定するようになりました。この環境変数は、Service 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 テンプレートを使用した Service Registry デプロイメントの設定
ApicurioRegistryCRD ファイルには、テクノロジープレビュー機能としてspec.deployment.podTemplateSpecPreviewフィールドが含まれるようになりました。spec.deployment.podTemplateSpecPreviewフィールドは、OpenShiftDeploymentリソースのspec.templateフィールドと構造 (PodTemplateSpec構造体) が同じです。いくつかの制限がありますが、Service Registry Operator は、このフィールドのデータを、Service Registry のDeploymentリソース内の対応するフィールドに転送します。この機能により、Apicurio Registry Operator で各ユースケースをネイティブにサポートする必要がなくなり、設定の柔軟性が向上します。重要テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能では、最新の製品機能をいち早く提供します。これにより、お客様は開発段階で機能をテストし、フィードバックを提供できます。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Service Registry ユーザーのドキュメントおよび例
ドキュメントライブラリーは、バージョン 2.4 で利用可能な新機能で更新されました。
オープンソースのデモンストレーションアプリケーションも更新されました。
2.4. 非推奨となった Service Registry の機能
Service Registry コアの非推奨機能
- Confluent Schema Registry API バージョン 6 (互換性 API): Service Registry は現在、異なるエンドポイントでの 2 つのバージョン (バージョン 6 とバージョン 7) の Confluent Schema Registry API の使用をサポートしています。バージョン 6 の使用は非推奨です。v6 API エンドポイントは今後のリリースで削除される予定です。v6 エンドポイントへのすべての参照を v7 API エンドポイントへの参照に置き換えてください。
- Service Registry Core API バージョン 1: Service Registry Core API の元のバージョン (バージョン 1) に対する Service Registry のサポートは非推奨になりました。従来の API は次のメジャーリリースで削除される予定です。
-
動的ログレベル設定:
/admin/loggersおよび/admin/loggers/{logger}API エンドポイントは、Service Registry Core API (v2) で非推奨になりました。これらのエンドポイントは今後のリリースで削除される予定です。 - Registry V1 エクスポートユーティリティー: コマンドラインエクスポートユーティリティーに対する Service Registry サポートは非推奨になりました。Service Registry 1.x から 2.x にインポートできる形式にデータをエクスポートするためのエクスポートツールに対するリリースおよびメンテナンスがなくなりました。すべてのお客様はすでに 1.x から 2.x にアップグレードしているはずです。
Service Registry Operator の非推奨機能
-
Deployment リソースの編集による環境変数の設定: 以前のバージョンでは、Service Registry Operator によってサポートされていた
Deploymentリソースを直接編集することで、Service Registry の環境変数を設定できました。ApicurioRegistryCRD ファイルのspec.configuration.envフィールドを使用して環境変数を管理できるようになったため、以前の手順は非推奨となり、それに対する Operator サポートは削除されます。Operator によって設定されていないすべての環境変数を設定するには、必ずspec.configuration.envフィールドを使用してください。 - 有効になっていない機能の環境変数の保持: Service Registry Operator は、KafkaSQL ストレージ使用時の Salted Challenge Response Authentication Mechanism (SCRAM) セキュリティーなど、さまざまな機能を有効にして設定するための環境変数を設定します。このような機能が無効になっている場合、Operator は現在、関連する環境変数を保持しているため、問題が発生する可能性があります。このような環境変数の保持は非推奨となり、それに対する Operator のサポートは削除されます。このような環境変数に依存するデプロイメントは使用しないようにしてください。
-
環境変数の優先順位: Service Registry Operator は、
spec.configuration.envフィールドですでに明示的に指定されている環境変数を設定しようとする場合があります。環境変数に競合する値がある場合、デフォルトでは、Service Registry Operator によって設定された値が優先されます。この動作は今後変更され、Operator によって設定されたほとんどの環境変数をユーザーが上書きできるようになります。デプロイメントが元の優先動作に依存していないことを確認してください。
2.5. Service Registry デプロイメントのアップグレードと移行
OpenShift では、Service Registry サーバーを Service Registry 2.x から Service Registry 2.4 に自動的にアップグレードできます。Service Registry 1.x から Service Registry 2.x への自動アップグレードはなく、移行プロセスが必要です。
2.5.1. 2.x クライアントの依存関係の更新
このリリースではクライアントの依存関係を更新することは必須ではありません。既存の 2.x クライアントは引き続き Service Registry 2.4 で動作します。
ただし、Service Registry の次のリリースの前に、クライアントアプリケーションのすべての依存関係を、最新の Service 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>
<dependency>
<groupId>io.apicurio</groupId>
<artifactId>apicurio-registry-client</artifactId>
<version>2.4.4.SP1-redhat-00001</version>
</dependency>詳細は、デフォルトで有効になっているレガシー REST API の日付形式 を参照してください。
2.5.2. OpenShift での Service Registry 2.x からのアップグレード
Service Registry 2.x on OpenShift 4.9 から Service Registry 2.4 on OpenShift 4.10 以降にアップグレードできます。Service Registry と OpenShift の両方のバージョンをアップグレードし、OpenShift のマイナーバージョンを 1 つずつアップグレードする必要があります。
前提条件
- すでに OpenShift 4.9 に Service 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 がデプロイされ、Service Registry Pod がデプロイされるまで待ちます。
- Service Registry システムが稼働中であることを確認します。
関連情報
- OpenShift Container Platform Web コンソールで Operator 更新チャネルを設定する方法の詳細は、Operator の更新チャネルの変更 を参照してください。
2.5.3. OpenShift での Service Registry 1.1 からの移行
Service Registry 1.1 から Service Registry 2.x に移行する方法の詳細は、Service Registry デプロイメントの移行 を参照してください。
2.6. Service Registry で解決された問題
| 問題 | 説明 |
|---|---|
| SerDes で Apache Avro の複合型を処理します。 | |
| Python SDK で、スネークケース以外のクエリーパラメーターを正しく処理します。 | |
| 動的 Basic 認証の Web コンソール解決を修正します。 | |
| レジストリーは古い Keycloak コンテキストパスを使用しています。 |
| 問題 | 説明 |
|---|---|
| Web コンソールで 匿名読み取りアクセス と アーティファクト所有者のみの認証 を有効にすると、エラーが発生して失敗します。 | |
| SSL を使用するように KafkaSQL ストレージを設定する場合、キーのパスワードはオプションではありません。 | |
|
JSON スキーマの互換性チェックが | |
|
Service Registry をデプロイするときに | |
|
| |
|
| |
|
| |
| 空のスキーマが提供された場合、互換性チェックでは例外が出力されません。 | |
|
スキーマのデフォルト値が | |
| 内部データベースの準備ができる前に、Kafka コンシューマースレッドが開始されます。 | |
| リダイレクトフィルターが正しく設定されていません。 | |
| 互換性ルールはバージョン番号順ではありません。 | |
| SASL が有効になっていないと、SSL 設定は機能しません。 | |
| registry.ccompat.use-canonical-hash 設定により、保存時にスキーマが正規化された形式に変更されます。 | |
| 間違った認証情報が認証サーバーに渡された場合、例外は出力されません。 | |
|
新しいバージョンの Protobuf スキーマのアップロードが | |
| REST API を使用してアーティファクトを作成するときに、名前と説明が正しく入力されません。 | |
| 最新バージョンが無効になっている場合は、スキーマの最新の有効バージョンを取得できません。 | |
| 複雑な配列オブジェクトの JSON スキーマ検証が失敗します。 |
Service Registry Operator で解決された問題
| 問題 | 説明 |
|---|---|
| CORS_ALLOWED_ORIGINS は、作成される OpenShift Pod の環境変数として伝播されません。 |
| 問題 | 説明 |
|---|---|
| Operator が作成したサービスにポート名が提供されていません。 | |
| デプロイメントが破棄された後に環境変数が欠落しています。 | |
| 環境変数の管理方法が間違って文書化されています。 | |
| ログレベルが正しく設定されていません。 |
2.7. Service Registry で解決された CVE
Service 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) 攻撃に対して脆弱である。 |
2.8. Service Registry の既知の問題
Service Registry 2.4.x には、次の既知の問題があります。
Service Registry コアの既知の問題
Registry-3413: レガシー REST API の日付形式がデフォルトで有効。
互換性を最大限に高め、Service Registry の古いバージョンから簡単にアップグレードできるように、OpenAPI 標準に準拠しない日付形式が REST API で使用されています (以前のバージョンのバグが原因)。
次の Service Registry リリースの前に、すべてのクライアントアプリケーションをアップグレードして最新のクライアントバージョンを使用するようにしてください。次のリリースでは日付形式のバグが修正されるため、古いクライアントは REST API と互換性がなくなります。
REST API を OpenAPI 準拠に更新するには、この バージョンの Service Registry の日付形式のバグを次のように修正します。
-
2.x クライアントの依存関係の更新 の説明に従って、すべてのクライアントアプリケーションをバージョン
2.4.4.SP1-redhat-00001に更新します。 次の環境変数を、以下に示されている値に設定します。
REGISTRY_APIS_V2_DATE_FORMAT=yyyy-MM-dd'T'HH:mm:ss'Z'
REGISTRY_APIS_V2_DATE_FORMAT=yyyy-MM-dd'T'HH:mm:ss'Z'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
IPT-814 - Service Registry のログアウト機能が RH-SSO 7.6 と互換性がない
RH-SSO 7.6 では、ログアウトエンドポイントで使用される redirect_uri パラメーターが非推奨になりました。詳細は、RH-SSO 7.6 アップグレードガイド を参照してください。これは非推奨であるため、RH-SSO Operator を使用して Service Registry のセキュリティー保護を行っている場合、 Logout ボタンをクリックすると、Invalid parameter: redirect_uri エラーが表示されます。
回避策は、https://access.redhat.com/solutions/6980926 を参照してください。
IPT-701 - CVE-2022-23221 H2 により、JNDI を介してリモートサーバーからカスタムクラスをロードできます
Service Registry データが AMQ Streams に保存されている場合、H2 データベースコンソールにより、リモート攻撃者は JDBC URL を使用して任意コードを実行できます。Service Registry はデフォルトで脆弱ではなく、悪意のある設定変更が必要になります。
Service Registry Operator の既知の問題
Operator-42: OpenShift ルートの自動生成では、間違ったベースホスト値が使用される可能性がある
複数の routerCanonicalHostname 値が指定されている場合、Service Registry OpenShift ルートの自動生成で間違ったベースホスト値が使用される可能性があります。
付録A サブスクリプションの使用
Integration は、ソフトウェアサブスクリプションを通じて提供されます。サブスクリプションを管理するには、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 をクリックして、Red Hat Integration ダウンロードページを表示します。
- コンポーネントの Download リンクをクリックします。
改訂日時: 2023-11-08
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}