リリースノート
概要
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
HCIDOCS プロジェクトの Jira 問題を作成してフィードバックを提供したり、エラーを報告したりすることができ、そこでは、フィードバックの進捗状況を追跡できます。Red Hat Jira アカウントがあり、ログインしている必要があります。
- Create Issue フォームを起動します。
Summary フィールド、Description フィールド、および Reporter フィールドに入力します。
Description フィールドに、ドキュメントの URL、章またはセクション番号、および問題の詳しい説明を入力します。
- Create をクリックします。
第1章 このリリースについて リンクのコピーリンクがクリップボードにコピーされました!
これらのリリースノートは、Red Hat OpenShift Container Platform 4.18 とともに OpenShift サンドボックスコンテナー 1.9 の開発を追跡します。リリースノートには元のチケットへのリンクが含まれています。プライベートチケットにはリンクがありません。
OpenShift Container Platform は FIPS 用に設計されています。FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
NIST の検証プログラムの詳細は、Cryptographic Module Validation Program を参照してください。検証のために提出された RHEL 暗号化ライブラリーの個別バージョンの最新の NIST ステータスは、政府の標準規格 を参照してください。
このリリースのメジャーバージョンとマイナーバージョンのセキュリティーとバグ修正を含むすべての アドバイザリー は、Red Hat カスタマーポータルで確認できます。
第2章 新機能および機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift sandboxed containers 1.9 で導入された新機能と拡張機能を説明します。
OpenShift Sandboxed Containers の Google Cloud サポート
Google Cloud で OpenShift Sandboxed Containers のワークロードを実行できるようになりました。OpenShift Sandboxed Containers は、昇格権限を必要とする CI などのワークロードの分離を強化します。
Jira:KATA-2414
Confidential Containers の initdata
Confidential Containers は、実行時にピア Pod を設定するための initdata 仕様をサポートするようになりました。これにより、ピア Pod の仮想マシンイメージに機密データを埋め込む必要がなくなります。この機能により、機密情報の漏洩が減り、セキュリティーが強化され、カスタムイメージビルドが不要になるため柔軟性が向上します。initdata 設定をグローバルに適用することも、特定の Pod に適用することもできます。
カスタムピア Pod 仮想マシンイメージのサポート
OpenShift Sandboxed Containers および Confidential Containers は、ピア Pod のカスタム仮想マシンイメージをサポートするようになりました。この機能を使用すると、ワークロード要件に合わせて調整されたイメージを選択できます。カスタムイメージは、Pod マニフェストにアノテーションを追加することによって参照され、ピア Pod の config map で指定されたデフォルトイメージをオーバーライドします。
Kata エージェントポリシーのカスタマイズ
Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは、どの操作が許可または拒否されるかを決定します。ピア Pod マニフェストにアノテーションを追加することで、testing または development のカスタムポリシーでデフォルトポリシーをオーバーライドできます。実稼働環境では、initdata を使用してポリシーを変更します。
デフォルトのクラスター認証情報の上書き
バージョン 1.7 以降、OpenShift sandboxed containers は、デフォルトで Cloud Credentials Operator によって提供される OpenShift Container Platform クラスターの認証情報を使用します。クラウドプロバイダーの認証情報を指定するピア Pod シークレットを作成することで、デフォルトの認証情報を上書きできます。Cloud Credentials Operator をアンインストールする場合は、ピア Pod シークレットを作成する必要があります。
Jira:KATA-2216
第3章 テクノロジープレビュー リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift sandboxed containers 1.9 で利用可能なすべてのテクノロジープレビューのリストを示します。
詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
IBM Z および IBM LinuxONE のピア Pod サポート
IBM Z® および IBM® LinuxONE (s390x アーキテクチャー) 上のピア Pod を使用することで、ネストされた仮想化なしで OpenShift サンドボックスコンテナーワークロードをデプロイできます。
Jira:KATA-2030
Microsoft Azure Cloud Computing Services、IBM Z、および IBM LinuxONE 上の Confidential Containers
Confidential Containers は、クラウドネイティブアプリケーションのセキュリティーを強化し、Trusted Execution Environments (TEE) と呼ばれる安全で分離された環境でアプリケーションを実行できるようにします。これにより、使用中でもコンテナーとそのデータが保護されます。
以下の制限事項に注意してください。
- 機密仮想マシン (CVM) ルートファイルシステム (rootfs) の暗号化と整合性保護はありません。CVM は TEE 内で実行され、コンテナーワークロードを実行します。rootfs の暗号化と整合性保護が不十分な場合、悪意のある管理者が rootfs に書き込まれた機密データを盗み出したり、rootfs データを改ざんしたりする可能性があります。rootfs の整合性保護と暗号化は現在進行中です。アプリケーションのすべての書き込みがメモリー内に確実に保存されるようにする必要があります。
- 暗号化されたコンテナーイメージはサポートされていません。現在、署名されたコンテナーイメージのサポートのみが利用可能です。暗号化されたコンテナーイメージのサポートの提供に向けて作業を進行しています。
- Kata shim と CVM 内のエージェントコンポーネント間の通信は改ざんされる可能性があります。CVM 内のエージェントコンポーネントは、OpenShift ワーカーノードで実行されている Kata shim から Kubernetes API コマンドを実行します。Kubernetes API 経由での機密データの流出を防ぐために、コンテナーの Kubernetes exec および log API をオフにするエージェントポリシーを CVM で使用します。ただし、これはまだ完了しておらず、シムとエージェントコンポーネント間の通信チャネルを強化するために、さらなる作業が進行中です。エージェントポリシーは、Pod アノテーションを使用して実行時にオーバーライドできます。現在、Pod 内のランタイムポリシーアノテーションは、アテステーションプロセスによって検証されていません。
- 暗号化された Pod 間通信はネイティブでサポートされていません。Pod 間通信は暗号化されていません。すべての Pod 間通信には、アプリケーションレベルで TLS を使用する必要があります。
- ワーカーノードと CVM 内でのイメージのダブルプル: コンテナーイメージは、TEE 内で実行される CVM にダウンロードされ、実行されます。ただし、現在はイメージはワーカーノードにもダウンロードされます。
- Confidential Containers の CVM イメージを構築するには、クラスターで OpenShift sandboxed containers Operator が使用可能である必要があります。
Jira:KATA-2416
第4章 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift Sandboxed Containers 1.9 の既知の問題を説明します。
Confidential Containers on Azure で、セキュアブートがデフォルトで無効になる
Confidential Containers on Azure で、セキュアブートがデフォルトで無効になっています。これはセキュリティー上のリスクです。この問題を回避するには、ピア Pod の config map を更新する ときに、ENABLE_SECURE_BOOT を true に設定します。
CPU がオフラインの場合、コンテナーの CPU リソース制限を増やせない
要求された CPU がオフラインの場合に、コンテナーの CPU リソース制限を使用して Pod で使用可能な CPU の数を増やすと失敗します。この機能が利用可能な場合は、oc rsh <pod> コマンドを実行して Pod にアクセスし、次に lscpu コマンドを実行することで、CPU リソースの問題を診断できます。
lscpu
$ lscpu
出力例:
CPU(s): 16 On-line CPU(s) list: 0-12,14,15 Off-line CPU(s) list: 13
CPU(s): 16
On-line CPU(s) list: 0-12,14,15
Off-line CPU(s) list: 13
オフライン CPU のリストは予測不可能で、実行ごとにリストが異なる可能性があります。
この問題を回避するには、次の例のように Pod アノテーションを使用して追加の CPU をリクエストします。
metadata:
annotations:
io.katacontainers.config.hypervisor.default_vcpus: "16"
metadata:
annotations:
io.katacontainers.config.hypervisor.default_vcpus: "16"
sizeLimit を増やしても一時ボリュームは拡張されない
ボリュームサイズはデフォルトで、sandboxed container に割り当てられたメモリーの 50% であるため、Pod 仕様の sizeLimit パラメーターを使用して一時ボリュームを拡張できません。
この問題を回避するには、ボリュームを再マウントしてサイズを変更します。たとえば、sandboxed container に割り当てられたメモリーが 6 GB で、一時ボリュームが /var/lib/containers にマウントされている場合、次のコマンドを実行して、このボリュームのサイズをデフォルトの 3 GB より大きくすることができます。
mount -o remount,size=4G /var/lib/containers
$ mount -o remount,size=4G /var/lib/containers
マウントコマンドは Pod 内で実行する必要があることに注意してください。これを Pod マニフェスト自体の一部として使用することも、oc rsh を実行して Pod 内でシェルセッションを起動し、mount コマンドを実行することもできます。
OpenShift Sandboxed Containers 1.7 以降は、OpenShift Container Platform 4.14 以前のバージョンでは動作しません。
OpenShift sandboxed containers Operator をインストールまたはアップグレードする前に、OpenShift Container Platform 4.15 以降にアップグレードする必要があります。詳細は、ナレッジベースの OpenShift sandboxed containers operator 1.7 is not available および Upgrade to OSC 1.7.0 put running Peer Pods into Container Creating status を参照してください。
AWS 上の Podvm Image Builder はスナップショットを残します
Podvm Image Builder はスナップショットから AMI イメージを作成しますが、適切なアンインストールプロセス中に AMI は削除されますが、スナップショット自体は削除されず、手動で削除する必要があります。
これは、AWS 上のすべてのピア Pod バージョンで発生します。
Jira:KATA-3478
クラスターを廃止する前に kataconfig を適切に削除しないと、アクティブな Pod 仮想マシンが実行したままになる可能性があります。
ピア Pod 機能がなければ、OSC Operator をアンインストールせずにクラスターを廃止できますが、ピア Pod を使用すると、Pod はクラスターワーカーノードの外部 (ピア Pod ごとに作成された podvm インスタンス上) で実行され、クラスターをシャットダウンする前に適切な kataconfig 削除が実行されないと、これらの podvm インスタンスは放棄され、終了されません。
Jira:KATA-3480