リリースノート
概要
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
KATA プロジェクトの Jira 課題を作成することで、フィードバックの提供やエラーの報告が可能です。作成した課題からフィードバックの進捗を追跡できます。Red Hat Jira アカウントがあり、ログインしている必要があります。
- Create Issue フォーム を起動します。
Summary フィールド、Description フィールド、および Reporter フィールドに入力します。
Description フィールドに、ドキュメントの URL、章またはセクション番号、および問題の詳しい説明を入力します。
- Create をクリックします。
第1章 このリリースについて リンクのコピーリンクがクリップボードにコピーされました!
これらのリリースノートは、Red Hat OpenShift Container Platform 4.19 とともに OpenShift sandboxed containers 1.10 の開発を追跡します。リリースノートには元のチケットへのリンクが含まれています。プライベートチケットにはリンクがありません。
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 ステータスは、コンプライアンスアクティビティーおよび政府標準 を参照してください。
第2章 新機能および機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift sandboxed containers 1.10 で導入された新機能と拡張機能を説明します。
Azure integrity-protected pod VM image
Azure 上で実行されるサンドボックスコンテナーと Confidential Containers に対して、Red Hat が作成したイメージがデフォルトで有効になり、コンテナーと仮想マシンイメージのセキュリティーが強化されました。
Google Cloud が、リソースタグの Pod 仮想マシンインスタンスへのバインドをサポートするようになる
ユーザーは、peer-pods-cm ConfigMap の TAGS フィールドを介してタグを設定できます。タグを適用するには、プロジェクトレベルでタグが存在している必要があります。
Azure 上の Confidential Containers
このリリースでは、セルフマネージド OpenShift クラスター内のすべての Azure 機密仮想マシンタイプ (Intel TDX、AMD SEV-SNP) で Confidential Containers を実行するための一般提供 (GA) サポートが有効になります。これにより、OpenShift サンドボックスコンテナー (Kata ベースの Pod) を、ハードウェアで分離された CVM 内で実行できるようになります。この CVM はメモリー暗号化に対応しており、その信頼性は Red Hat build of Trustee を用いたリモートアテステーションによって検証されます。アテステーションの成功後には、CVM 内部へのシールドされたシークレットのプロビジョニングもサポートされます。
第3章 バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift sandboxed containers 1.10 で修正されたバグを説明します。
Openshift サンドボックスコンテナーでクロックドリフトが確認される
原因: ベアメタル上のサンドボックスコンテナーでクロックドリフトが確認されます。影響: タイムクリティカルなワークロードの動作が劣化、または失敗する可能性があります。修正: Kata ゲストクロックがホストクロックと同期されるようになりました。結果: ドリフトが確認されなくなりました。
第4章 テクノロジープレビュー リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift sandboxed containers 1.10 で利用可能なすべてのテクノロジープレビューのリストを示します。
詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
IBM Z および IBM LinuxONE のピア Pod サポート
IBM Z® および IBM® LinuxONE (s390x アーキテクチャー) 上のピア Pod を使用することで、ネストされた仮想化なしで OpenShift サンドボックスコンテナーワークロードをデプロイできます。
Jira:KATA-2030
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 サンドボックスコンテナー Operator が使用可能である必要があります。
Jira:KATA-2416
第5章 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift sandboxed containers 1.10 の既知の問題を説明します。
CPU がオフラインの場合、コンテナーの CPU リソース制限を増やせない
要求された CPU がオフラインの場合に、コンテナーの CPU リソース制限を使用して Pod で使用可能な CPU の数を増やすと失敗します。この機能が利用可能な場合は、oc rsh <pod> コマンドを実行して Pod にアクセスし、次に lscpu コマンドを実行することで、CPU リソースの問題を診断できます。
$ lscpu
出力例:
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"
sizeLimit を増やしても一時ボリュームは拡張されない
ボリュームサイズはデフォルトで、sandboxed container に割り当てられたメモリーの 50% であるため、Pod 仕様の sizeLimit パラメーターを使用して一時ボリュームを拡張できません。
この問題を回避するには、ボリュームを再マウントしてサイズを変更します。たとえば、sandboxed container に割り当てられたメモリーが 6 GB で、一時ボリュームが /var/lib/containers にマウントされている場合、次のコマンドを実行して、このボリュームのサイズをデフォルトの 3 GB より大きくすることができます。
$ mount -o remount,size=4G /var/lib/containers
マウントコマンドは Pod 内で実行する必要があることに注意してください。これを Pod マニフェスト自体の一部として使用することも、oc rsh を実行して Pod 内でシェルセッションを起動し、mount コマンドを実行することもできます。