5.2. Compliance Operator リリースノート


Compliance Operator を使用すると、OpenShift Container Platform 管理者はクラスターの必要なコンプライアンス状態を記述し、存在するギャップやそれらを修復する方法に関する概要を提供します。

以下のリリースノートは、OpenShift Container Platform の Compliance Operator の開発履歴を記録したものです。

Compliance Operator の概要は、Understanding the Compliance Operator を参照してください。

最新リリースにアクセスするには、コンプライアンス Operator の更新 を参照してください。

すべての Red Hat 製品のコンプライアンスサポートの詳細は、Product Compliance を参照してください。

5.2.1. OpenShiftCompliance Operator1.8.0

OpenShift Compliance Operator 1.8.0 に関する次のアドバイザリーが利用可能です。

5.2.1.1. 新機能および機能拡張

  • この更新により、Compliance Operator は TECH PREVIEW ステータスの Common Expression Language (CEL) スキャナーを提供します。CEL スキャナーは、管理者が CEL 式を使用してカスタムセキュリティーポリシーを定義および適用できるようにする新しい CustomRule カスタムリソース定義 (CRD) を実装します。この新しいコンテンツ形式は、既存の XCCDF (Extensible Configuration Checklist Description Format) プロファイルを置き換えるものではなく、カスタムセキュリティーポリシーに準拠する機能を拡張します。詳細は (CMP-3118) を参照してください。
  • 以前は、Compliance Operator では生のスキャン結果を保存するために永続的なストレージが必要であり、エッジデプロイメントやストレージインフラストラクチャーのない環境では課題となっていました。このリリースでは、Compliance Operator は永続ストレージなしでのスキャンの実行をサポートします。管理者は、ScanSetting リソースで rawResultStorage.enabled: false を設定してスキャン結果ファイルの保存を無効にし、エッジデプロイメントやシングルノードの OpenShift などのストレージが制限された環境でコンプライアンススキャンを実行できるようにすることができます。コンプライアンスチェックの結果は、ComplianceCheckResult リソースを通じて完全に利用できます。下位互換性を保つため、生の結果の保存はデフォルトで有効になっています。詳細は (CMP-1225) を参照してください。
  • 以前は、Compliance Operator は、BSI コンプライアンススキャン用に ocp4-bsi および ocp4-bsi-node プロファイルを提供していました。このリリースでは、rhcos4-bsi プロファイルが利用可能になり、BSI 標準の範囲が RHCOS システムに拡張されました。詳細は (CMP-3720) を参照してください。
  • このリリースでは、廃止された CIS 1.4.0、CIS 1.5.0、DISA STIG V1R1、および DISA STIG V2R1 プロファイルが削除されます。新しいバージョンでは、これらの古いプロファイルがお客様用に置き換えられました。詳細は (CMP-3712) を参照してください。
  • このリリースでは、PCI-DSS プロファイル 3.2.1 および 4.0.0 が ARM アーキテクチャーシステムでサポートされるようになりました。詳細は、(CMP-3723) を参照してください。

5.2.1.2. バグ修正

  • このリリースでは、API サーバー暗号化の自動修復により、OpenShift のバージョンに基づいて適切な暗号化モードが適用されるようになりました。OpenShift 4.13.0 以降のバージョンでは AES-GCM、それより前のバージョンでは AES-CBC です。両方の暗号化モードは、すべての OpenShift バージョン間で準拠し続けます。詳細は (CMP-3248) を参照してください。
  • このリリースより前では、Compliance Operator はすべての SSH 強化設定を含む固定の sshd_config ファイルをデプロイすることで、RHCOS ホスト上の SSH 設定を修正していました。対応するルールのスキャンが失敗した場合、SSH に意図しない設定変更が生じる可能性があります。このリリースでは、Compliance Operator は、https://github.com/ComplianceAsCode/content/blob/master/shared/macros/10-kubernetes.jinja#L1-L154 に示されているルールに従って、SSH に非常に具体的な修復を適用します。詳細は (CMP-3553) を参照してください。
  • 以前のバージョンの Compliance Operator では、ログローテーション機能は /etc/cron.daily フォルダー内の logrotate ファイルの検索に依存していました。このリリースでは、Compliance Operator は logrotate.timer サービスと連携します。これにより、Compliance Operator からの信頼性の高いログローテーション動作が提供されます。
  • 以前のバージョンの Compliance Operator では、コンプライアンスレポートから STIG ID を省略できる可能性があります。これらの省略は、stigref 値stigid 値の欠落によって発生しました。このリリースでは、欠落が修正され、コンプライアンスレポートに STIG ID が 確実に表示されるようになりました。
  • このリリースより前では、Compliance OperatorSTIG コントロール CNTR-OS-000720 はルール rhcos4-audit-rules-suid- 特権 -function を選択しましたが、このルールは Compliance Operator で使用できなかったため、出力は生成されませんでした。このリリースでは、ルール rhcos4-audit-rules-suid- 特権 -function が Compliance Operator で使用できるようになり、スキャン出力にリストされるようになりました。詳細は、(CMP-3558) を参照してください。
  • 以前のバージョンの Compliance Operator では、TLS が正しく有効になっている場合でも、ocp4-stig プロファイルを使用したスキャンは、ルール ocp4-stig-modified-audit-log-forwarding-uses-tls で失敗していました。これは、ClusterLogForwarder リソースで tls:// フィールドが不要になり、スキャン出力に誤った FAIL 結果が表示されるために発生します。このリリースでは、プロトコル接頭辞は必要なくなり、スキャン出力で正しい結果が生成されます。詳細は、ODF 4.11 がインストールされている場合に routes-protected-by-tls コンプライアンスチェックが失敗する を参照してください。
  • 以前は、CIS ベンチマークコントロール 1.2.31 または 1.2.33 で推奨されているように、API サーバーがサポートされていない設定オーバーライドを使用しているかどうかを自動的に確認する方法はありませんでした。このリリースでは、サポートされていない設定のオーバーライドをチェックするための専用ルールが提供されます。
  • Compliance Operator の以前のリリースでは、ルール resource-requests-limits など、一部のルールのアノテーションに変数参照がありませんでした。このリリースでは、変数参照がルールで使用できるようになり、誤った出力が排除されました。詳細は、(CMP-3582) を参照してください。
  • 以前は、ocp4-routes-rate-limit ルールでは、openshift および kube 名前空間の外部にあるすべてのルートにレート制限を設定する必要がありました。ただし、重要な Operator によって管理される他の名前空間は変更されるべきではなく、Compliance Operator によって変更がスキャンされるべきではないため、この機能を使用してスキャンすると問題が発生します。このリリースでは、重要な Operator によって管理されるルートは、Compliance Operator によってエラーとしてフラグ付けされません。
  • 以前のバージョンの Compliance Operator では、openshift-sdn ネットワークプロバイダーが見つからない場合、ComplianceScan によって SDN が見つかりません という警告が報告されていました。このリリースでは、OpenShift-SDN がアクティブなネットワークプロバイダーではない場合に、Compliance Operator によって警告が抑制されます。詳細は (CMP-3591) を参照してください。
  • 以前は、TailoredProfile で重複した変数が誤って作成され、Compliance Operator によって正しく検出されない可能性がありました。このリリースでは、TailoredProfile 内の重複した setValues が識別され、コンプライアンススキャンから警告イベントがトリガーされます。
  • Compliance Operator の以前のリリースでは、clusterlogforwarder 出力設定に URL キーのないマップが含まれている場合、ルール ocp4-audit-log-forwarding-uses-tls が失敗していました。このリリースでは、ルールは URL フィールドを持つ出力を正しくフィルタリングし、clusterlogforwarder に対して TLS が適切に有効になっている場合に PASS を表示します。詳細は、(CMP-3597) を参照してください。
  • 以前のバージョンの Compliance Operator では、ルール rhcos4-service-systemd-coredump-disabled の場合、クラスターのスキャン後に修復は生成されませんでした。このリリースでは、rhcos4-service-systemd-coredump-disabled の修復が提供されています。
  • 以前のバージョンの Compliance Operator では、imagestream.spec.tags.importPolicy.scheduled の設定をチェックするルールは、設定が正しい場合でも FAIL を返していました。このリリースでは、ルールによって、サンプルオペレーターによって管理されるイメージストリームと ClusterVersion によって所有されるイメージストリームが正しく除外されるようになり、コンプライアンスステータスのレポートが正確に行われるようになりました。
  • 以前のリリースでは、Compliance Operator には、サポートされていない設定オーバーライドと不具合のある修復機能を使用する古い TLS 暗号スイートルールが含まれていました。このリリースでは、これらの古いルールはデフォルトのプロファイルから削除されました。また、整理しやすくするために、ocp4-kubelet-configure-tls-cipher-suites-ingresscontroller ルールの名前が ocp4-ingress-controller-tls-cipher-suites に変更されました。詳細は、(CMP-3606) を参照してください。
  • 以前のバージョンの Compliance Operator では、カスタムコンテンツイメージを使用して ComplianceScans を 直接作成すると、プロファイルの非推奨チェック中に失敗しました。このリリースでは、Compliance Operator は ProfileBundle を 判別できない場合を適切に処理し、スキャンを失敗させる代わりに情報メッセージをログに記録します。詳細は、(CMP-3613) を参照してください。
  • 以前は、Compliance Operator は 、ocp4-routes-protected-by-tls ルールに準拠していないと誤ってフラグ付けされたパススルールートをスキャンしていました。このリリースでは、パススルールートは TLS 終了をバックエンドアプリケーションに委任するため、このルールから適切に除外されます。

5.2.2. OpenShift Compliance Operator 1.7.1

OpenShift Compliance Operator 1.7.1 については、次のアドバイザリーが利用できます。

5.2.2.1. バグ修正

  • 以前は、Compliance Operator の 一時停止 コンテナーはメモリー不足により終了し、ステータスが表示されることがありました。 OOMKilled)。この更新により、`pauser`のメモリー制限がコンテナーを増やすことでエラーを防ぎ、全体的な安定性が向上します。(OCPBUGS-50924)

5.2.3. OpenShift Compliance Operator 1.7.0

OpenShift Compliance Operator 1.7.0 については、次のアドバイザリーが利用できます。

5.2.3.1. 新機能および機能拡張

  • aarch64x86ppc64le、および s390x アーキテクチャーにインストールされた Compliance Operator で、must-gather 拡張機能が利用できるようになりました。must-gather ツールは、Red Hat Customer Support チームおよびエンジニアリングチームに重要な設定の詳細を提供するものです。詳細は、Compliance Operator の must-gather ツールの使用 を参照してください。
  • CIS Benchmark のサポートが Compliance Operator 1.7.0 に追加されました。サポートされているプロファイルは、CIS OpenShift Benchmark 1.7.0 です。詳細は、(CMP-3081) を参照してください。
  • Compliance Operator が、CIS OpenShift Benchmark 1.7.0 および FedRAMP Moderate Revision 4 の aarch64 アーキテクチャーでサポートされるようになりました。詳細は、(CMP-2960) を参照してください。
  • Compliance Operator 1.7.0 で、OpenShift および RHCOS の OpenShift DISA STIG V2R2 プロファイルがサポートされるようになりました。詳細は、(CMP-3142) を参照してください。
  • Compliance Operator 1.7.0 で、サポートされていない古いプロファイルバージョンの非推奨 (CIS 1.4 プロファイル、CIS 1.5 プロファイル、DISA STIG V1R1 プロファイル、DISA STIG V2R1 プロファイルの非推奨など) がサポートされるようになりました。詳細は、(CMP-3149) を参照してください。
  • Compliance Operator 1.7.0 のリリースにより、古い CIS および DISA STIG プロファイルが非推奨になりました。これらの古いプロファイルは、Compliance Operator 1.8.0 の公開とともにサポートされなくなる予定です。詳細は、(CMP-3284) を参照してください。
  • Compliance Operator 1.7.0 のリリースにより、OpenShift に BSI プロファイルのサポートが追加されました。詳細は、KCS の記事 BSI クイックチェック および BSI コンプライアンスサマリー を参照してください。

5.2.3.2. バグ修正

  • このリリースの前は、Compliance Operator が不要な修復推奨事項を提供していました。これは、s390x アーキテクチャーのファイルシステム構造の違いが原因でした。このリリースでは、Compliance Operator がファイルシステム構造の違いを認識するようになり、誤解を招く修復を提供しなくなりました。この更新により、ルールがより明確に定義されるようになりました。(OCPBUGS-33194)
  • 以前は、ルール ocp4-etcd-unique-ca の指示が OpenShift 4.17 以降で機能しませんでした。この更新により、この指示と実行可能な手順が修正されました。(OCPBUGS-42350)
  • Compliance Operator を Cluster Logging Operator (CLO) バージョン 6.0 と併用すると、さまざまなルールが失敗します。これは、CLO が使用する CRD に対する下位互換性のない変更が原因です。Compliance Operator は、この CRD を利用してロギング機能を検証しています。この CRD が修正され、PCI-DSS プロファイルと CLO の併用がサポートされるようになりました。(OCPBUGS-43229)
  • ユーザーが Cluster Logging Operator (CLO) 6.0 をインストールすると、ComplianceCheckResult の ocp4-cis-audit-log-forwarding-enabled が失敗していました。これは、clusterlogforwarder リソースの APIversion の変更が原因でした。現在は、ログの収集と転送の設定が新しい API で指定されるようになりました。この API は、observability.openshift.io API グループに含まれています。(OCPBUGS-43585)
  • Compliance Operator の以前のリリースでは、スキャンによって Operator Pod のリコンサイルループのエラーログが生成されていました。このリリースでは、Compliance Operator コントローラーのロジックの安定性が向上しました。(OCPBUGS-51267)
  • 以前は、file-integrity-exists または file-integrity-notification-enabled ルールが、aarch64 OpenShift クラスターで失敗していました。この更新により、これらのルールが aarch64 システムでは NOT-APPLICABLE と評価されるようになりました。(OCPBUGS-52884)
  • この Compliance Operator のリリース前は、ルール kubelet-configure-tls-cipher-suites が API サーバーの暗号で失敗し、E2E-FAILURE ステータスになっていました。このルールは、OpenShift 4.18 に含まれる RFC 8446 の新しい暗号をチェックするように更新されました。このルールは正しく評価されるようになりました。(OCPBUGS-54212)
  • 以前は、Compliance Operator プラットフォームのスキャンが失敗し、failed to parse Ignition config というメッセージが生成されていました。このリリースにより、バージョン 4.19 の OpenShift がお客様に提供されたときに、そのバージョンのクラスター上で Compliance Operator を安全に実行できるようになりました。(OCPBUGS-54403)
  • この Compliance Operator のリリース前は、いくつかのルールがプラットフォームを認識せず、不要なエラーが発生していました。これらのルールは、他のアーキテクチャーに適切に移植されたため、正しく実行されるようになりました。ユーザーが使用しているアーキテクチャーに応じて、コンプライアンスチェック結果に NOT-APPLICABLE と適切に表示されます。(OCPBUGS-53041)
  • 以前は、ルール file-groupowner-ovs-conf-db-hugetlbf が予期せず失敗していました。このリリースでは、ルールの失敗が必要な結果である場合にのみ発生するようになりました。(OCPBUGS-55190)

5.2.4. OpenShift Compliance Operator 1.6.2

OpenShift Compliance Operator 1.6.2 については、次のアドバイザリーが利用できます。

CVE-2024-45338 は、Compliance Operator 1.6.2 リリースで解決されています。(CVE-2024-45338)

5.2.5. OpenShift Compliance Operator 1.6.1

OpenShift Compliance Operator 1.6.1 については、次のアドバイザリーが利用できます。

この更新には、基礎となるベースイメージの依存関係のアップグレードが含まれています。

5.2.6. OpenShift Compliance Operator 1.6.0

OpenShift Compliance Operator 1.6.0 については、次のアドバイザリーが利用できます。

5.2.6.1. 新機能および機能拡張

  • Compliance Operator には現在、Payment Card Industry Data Security Standard (PCI-DSS) バージョン 4 でサポートされているプロファイルが含まれています。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
  • Compliance Operator には現在、Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) V2R1 でサポートされているプロファイルが含まれています。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
  • x86ppc64le、および s390x アーキテクチャーにインストールされた Compliance Operator で、must-gather 拡張が利用できるようになりました。must-gather ツールは、Red Hat Customer Support チームおよびエンジニアリングチームに重要な設定の詳細を提供するものです。詳細は、Compliance Operator の must-gather ツールの使用 を参照してください。

5.2.6.2. バグ修正

  • このリリース前は、ocp4-route-ip-whitelist ルールの誤解を招くような説明により誤解が生じ、誤った設定が発生する可能性がありました。この更新により、ルールがより明確に定義されるようになりました。(CMP-2485)
  • 以前は、DONE ステータスの ComplianceScan のすべての ComplianceCheckResults のレポートが不完全でした。この更新により、ステータスが DONE である ComplianceScanComplianceCheckResults の合計数を報告するためのアノテーションが追加されました。(CMP-2615)
  • 以前は、ocp4-cis-scc-limit-container-allowed-capabilities ルールの説明に曖昧なガイドラインが含まれていたため、ユーザーの間で混乱が生じていました。この更新により、ルールの説明と実行可能な手順が明確になりました。(OCPBUGS-17828)
  • この更新前は、sysctl 設定により、RHCOS4 ルールの特定の自動修復が、影響を受けるクラスターでスキャンに失敗していました。この更新により、正しい sysctl 設定が適用され、FedRAMP High プロファイルの RHCOS4 ルールが正しくスキャンされるようになりました。(OCPBUGS-19690)
  • この更新前は、jq フィルターの問題により、コンプライアンスチェック中に rhacs-operator-controller-manager デプロイメントでエラーが発生していました。この更新により、jq フィルター式が更新され、rhacs-operator-controller-manager デプロイメントはコンテナーリソース制限に関するコンプライアンスチェックから免除され、誤検知の結果が排除されます。(OCPBUGS-19690)
  • この更新前は、rhcos4-high および rhcos4-moderate プロファイルは、誤ったタイトルの設定ファイルの値をチェックしていました。その結果、一部のスキャンチェックが失敗する可能性がありました。この更新により、rhcos4 プロファイルは正しい設定ファイルをチェックし、正しくスキャンされるようになりました。(OCPBUGS-31674)
  • 以前は、oauthclient-inactivity-timeout ルールで使用される accessokenInactivityTimeoutSeconds 変数はイミュータブルだったため、DISA STIG スキャンを実行すると FAIL ステータスになりました。この更新により、accessTokenInactivityTimeoutSeconds 変数の適切な適用が正しく動作し、PASS ステータスが可能になりました。(OCPBUGS-32551)
  • この更新前は、ルールの一部のアノテーションが更新されず、誤った制御標準が表示されていました。この更新により、ルールのアノテーションが正しく更新され、正しい制御標準が表示されるようになります。(OCPBUGS-34982)
  • 以前は、Compliance Operator 1.5.1 にアップグレードすると、ServiceMonitor 設定で誤って参照されたシークレットが原因で、Prometheus Operator とのインテグレーションの問題が発生していました。この更新により、Compliance Operator は ServiceMonitor メトリクスのトークンを含むシークレットを正確に参照するようになります。(OCPBUGS-39417)

5.2.7. OpenShift Compliance Operator 1.5.1

OpenShift Compliance Operator 1.5.1 については、次のアドバイザリーが利用できます。

5.2.8. OpenShift Compliance Operator 1.5.0

OpenShift Compliance Operator 1.5.0 については、次のアドバイザリーが利用できます。

5.2.8.1. 新機能および機能拡張

  • この更新により、Compliance Operator はプログラムで容易に使用できる一意のプロファイル ID を提供します。(CMP-2450)
  • このリリースでは、Compliance Operator が ROSA HCP 環境でテストされ、サポートされるようになりました。Compliance Operator は、ROSA HCP 上で実行されるとノードプロファイルのみを読み込みます。これは、Red Hat が管理するプラットフォームではコントロールプレーンへのアクセスが制限され、Platform プロファイルが Operator の機能とは無関係になるためです (CMP-2581)。

5.2.8.2. バグ修正

  • CVE-2024-2961 は、Compliance Operator 1.5.0 リリースで解決されています。(CVE-2024-2961)
  • 以前は、ROSA HCP システムにおけるプロファイルリストが正しくありませんでした。この更新により、Compliance Operator のプロファイル出力が正しくなりました。(OCPBUGS-34535)
  • このリリースでは、カスタマイズされたプロファイルで ocp4-var-network-policies-namespaces-exempt-regex 変数を設定することにより、namespace を ocp4-configure-network-policies-namespaces チェックから除外できるようになりました。(CMP-2543)

5.2.9. OpenShift Compliance Operator 1.4.1

OpenShift Compliance Operator 1.4.1 については、次のアドバイザリーが利用できます。

5.2.9.1. 新機能および機能拡張

  • このリリース以降、Compliance Operator は CIS OpenShift 1.5.0 プロファイルルールを提供するようになりました。(CMP-2447)
  • この更新により、Compliance Operator がプロファイルルールとともに OCP4 STIG IDSRG を提供するようになりました。(CMP-2401)
  • この更新により、s390x に適用されていた古いルールが削除されました。(CMP-2471)

5.2.9.2. バグ修正

  • 以前は、Red Hat Enterprise Linux (RHEL) 9 を使用する Red Hat Enterprise Linux CoreOS (RHCOS) システムでは、ocp4-kubelet-enable-protect-kernel-sysctl-file-exist ルールの適用に失敗していました。この更新により、ルールが ocp4-kubelet-enable-protect-kernel-sysctl に置き換えられました。自動修復が適用されると、RHEL9 ベースの RHCOS システムでは、このルールの適用時に PASS と表示されるようになりました。(OCPBUGS-13589)
  • 以前は、プロファイル rhcos4-e8 を使用してコンプライアンス修正を適用した後、コアユーザーアカウントへの SSH 接続を使用してノードにアクセスできなくなりました。この更新により、ノードは `sshkey1 オプションを使用して SSH 経由でアクセス可能になります。(OCPBUGS-18331)
  • 以前は、STIG プロファイルに、OpenShift Container Platform 用に公開された STIG の要件を満たす CaC のルールがありませんでした。この更新により、修復時に、Compliance Operator を使用して修復できる STIG 要件をクラスターが満たすようになります。(OCPBUGS-26193)
  • 以前は、複数の製品に対して異なるタイプのプロファイルを持つ ScanSettingBinding オブジェクトを作成すると、バインディング内の複数の製品タイプに対する制限が回避されていました。この更新により、ScanSettingBinding オブジェクトのプロファイルタイプに関係なく、製品検証で複数の製品が許可されるようになりました。(OCPBUGS-26229)
  • 以前は、自動修復が適用された後でも、rhcos4-service-debug-shell-disabled ルールを実行すると、FAIL と表示されていました。この更新により、自動修復が適用された後に rhcos4-service-debug-shell-disabled ルールを実行すると、PASS と表示されるようになりました。(OCPBUGS-28242)
  • この更新により、rhcos4-banner-etc-issue ルールの使用手順が強化され、より詳細な情報が提供されるようになりました。(OCPBUGS-28797)
  • 以前は、api_server_api_priority_flowschema_catch_all ルールが OpenShift Container Platform 4.16 クラスターで FAIL ステータスを示していました。この更新により、api_server_api_priority_flowschema_catch_all ルールが OpenShift Container Platform 4.16 クラスターで PASS ステータスを示すようになりました。(OCPBUGS-28918)
  • 以前は、ScanSettingBinding (SSB) オブジェクトに表示される完了したスキャンからプロファイルを削除した場合、Compliance Operator が古いスキャンを削除しませんでした。その後、削除したプロファイルを使用して新しい SSB を起動すると、Compliance Operator が結果を更新できませんでした。この Compliance Operator のリリースでは、新しい SSB に新しいコンプライアンスチェック結果が表示されるようになりました。(OCPBUGS-29272)
  • 以前は、ppc64le アーキテクチャーでは、メトリクスサービスが作成されませんでした。この更新により、Compliance Operator v1.4.1 を ppc64le アーキテクチャーにデプロイするときに、メトリクスサービスが正しく作成されるようになりました。(OCPBUGS-32797)
  • 以前は、HyperShift ホステッドクラスターでは、filter cannot iterate 問題により、ocp4-pci-dss profile を使用したスキャンで回復不能なエラーが発生していました。このリリースでは、ocp4-pci-dss プロファイルのスキャンが done ステータスに達し、Compliance または Non-Compliance のテスト結果が返されます。(OCPBUGS-33067)

5.2.10. OpenShift Compliance Operator 1.4.0

OpenShift Compliance Operator 1.4.0 については、次のアドバイザリーが利用できます。

5.2.10.1. 新機能および機能拡張

  • この更新により、デフォルトの worker および master ノードプール以外のカスタムノードプールを使用するクラスターで、Compliance Operator がそのノードプールの設定ファイルを確実に集約するための追加変数を指定する必要がなくなりました。
  • ユーザーは、ScanSetting.suspend 属性を True に設定することで、スキャンスケジュールを一時停止できるようになりました。これにより、ユーザーは ScanSettingBinding を削除して再作成することなく、スキャンスケジュールを一時停止し、再アクティブ化できます。そのため、メンテナンス期間中のスキャンスケジュールを簡単に一時停止できます。(CMP-2123)
  • Compliance Operator は、Profile カスタムリソースでオプションの version 属性をサポートするようになりました。(CMP-2125)
  • Compliance Operator は、ComplianceRules のプロファイル名をサポートするようになりました。(CMP-2126)
  • このリリースでは、cronjob API が改良された Compliance Operator の互換性を使用できます。(CMP-2310)

5.2.10.2. バグ修正

  • 以前は、Windows ノードがコンプライアンススキャンでスキップされなかったため、Windows ノードを含むクラスターでは、自動修復の適用後に一部のルールが失敗していました。このリリースでは、スキャン時に Windows ノードが正しくスキップされます。(OCPBUGS-7355)
  • この更新により、rprivate のデフォルトのマウント伝播が、マルチパス構成に依存する Pod のルートボリュームマウントに対して正しく処理されるようになりました。(OCPBUGS-17494)
  • 以前は、Compliance Operator は、修復の適用中であってもルールを調整せずに coreos_vsyscall_kernel_argument の修復を生成していました。リリース 1.4.0 では、coreos_vsyscall_kernel_argument ルールがカーネル引数を適切に評価し、適切な修復を生成するようになりました。(OCPBUGS-8041)
  • この更新より前は、自動修復が適用された後でも、rhcos4-audit-rules-login-events-faillock のルールが失敗していました。この更新により、rhcos4-audit-rules-login-events-faillock の失敗ロックが自動修復後に正しく適用されるようになりました。(OCPBUGS-24594)
  • 以前は、Compliance Operator 1.3.1 から Compliance Operator 1.4.0 にアップグレードすると、OVS ルールのスキャン結果が PASS から NOT-APPLICABLE に変わりました。この更新により、OVS ルールのスキャン結果に PASS が表示されるようになりました (OCPBUGS-25323)

5.2.11. OpenShift Compliance Operator 1.3.1

OpenShift Compliance Operator 1.3.1 については、次のアドバイザリーが利用できます。

この更新は、基礎となる依存関係の CVE に対処するものです。

5.2.11.1. 新機能および機能拡張

  • Compliance Operator は、FIPS モードで実行されている OpenShift Container Platform クラスターにインストールして使用できます。

    重要

    クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から 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 暗号化ライブラリーを使用します。

5.2.11.2. 既知の問題

  • Windows ノードがコンプライアンススキャンでスキップされないため、Windows ノードを含むクラスターでは、自動修復の適用後に一部のルールが失敗します。スキャン時に Windows ノードをスキップする必要があるため、これは想定される結果とは異なります。(OCPBUGS-7355)

5.2.12. OpenShift Compliance Operator 1.3.0

OpenShift Compliance Operator 1.3.0 については、次のアドバイザリーが利用できます。

5.2.12.1. 新機能および機能拡張

  • OpenShift Container Platform の国防情報システム局セキュリティ技術導入ガイド (DISA-STIG) が、Compliance Operator 1.3.0 から利用できるようになりました。詳細は、サポート対象のコンプライアンスプロファイル を参照してください。
  • Compliance Operator 1.3.0 は、NIST 800-53 Moderate-Impact Baseline for OpenShift Container Platform のプラットフォームおよびノードプロファイルに対応する IBM Power® および IBM Z® をサポートするようになりました。

5.2.13. OpenShift Compliance Operator 1.2.0

OpenShift Compliance Operator 1.2.0 については、次のアドバイザリーが利用できます。

5.2.13.1. 新機能および機能拡張

  • CIS OpenShift Container Platform 4 Benchmark v1.4.0 プロファイルがプラットフォームおよびノードアプリケーションで利用できるようになりました。CIS OpenShift Container Platform v4 ベンチマークを見つけるには、CIS Benchmarks にアクセスし、Download Latest CIS Benchmark をクリックします。そこで登録すると、ベンチマークをダウンロードできます。

    重要

    Compliance Operator 1.2.0 にアップグレードすると、CIS OpenShift Container Platform 4 Benchmark 1.1.0 プロファイルが上書きされます。

    OpenShift Container Platform 環境に既存の cis および cis-node 修復が含まれている場合は、Compliance Operator 1.2.0 にアップグレードした後のスキャン結果に多少の違いが生じる可能性があります。

  • scc-limit-container-allowed-capabilities ルールで、Security Context Constraints (SCC) の監査に関する明確性がさらに向上しました。

5.2.14. OpenShift Compliance Operator 1.1.0

OpenShift Compliance Operator 1.1.0 には、以下のアドバイザリーを利用できます。

5.2.14.1. 新機能および機能拡張

  • ComplianceScan カスタムリソース定義 (CRD) ステータスで開始および終了のタイムスタンプが利用できるようになりました。
  • Subscription ファイルを作成することで、OperatorHub を使用して Compliance Operator を Hosted Control Plane にデプロイできるようになりました。詳細は、Hosted Control Plane への Compliance Operator のインストール を参照してください。

5.2.14.2. バグ修正

  • 今回の更新前は、Compliance Operator ルールの指示の一部が存在していませんでした。今回の更新後、以下のルールの手順が改善されました。

    • classification_banner
    • oauth_login_template_set
    • oauth_logout_url_set
    • oauth_provider_selection_set
    • ocp_allowed_registries
    • ocp_allowed_registries_for_import

      (OCPBUGS-10473)

  • この更新前は、チェックの精度とルールの指示が不明確でした。今回の更新後、次の sysctl ルールのチェック精度と手順が改善されました。

    • kubelet-enable-protect-kernel-sysctl
    • kubelet-enable-protect-kernel-sysctl-kernel-keys-root-maxbytes
    • kubelet-enable-protect-kernel-sysctl-kernel-keys-root-maxkeys
    • kubelet-enable-protect-kernel-sysctl-kernel-panic
    • kubelet-enable-protect-kernel-sysctl-kernel-panic-on-oops
    • kubelet-enable-protect-kernel-sysctl-vm-overcommit-memory
    • kubelet-enable-protect-kernel-sysctl-vm-panic-on-oom

      (OCPBUGS-11334)

  • 今回の更新以前は、ocp4-alert-receiver-configured ルールに命令が含まれていませんでした。今回の更新により、ocp4-alert-receiver-configured ルールに含まれる命令が改善されました。(OCPBUGS-7307)
  • 今回の更新より前は、rhcos4-sshd-set-loglevel-info ルールは rhcos4-e8 プロファイルでは失敗していました。この更新により、sshd-set-loglevel-info ルールの修復が更新され、正しい設定変更が適用され、修復の適用後に後続のスキャンが通過できるようになりました。(OCPBUGS-7816)
  • 今回の更新の前は、最新の Compliance Operator インストールを使用した OpenShift Container Platform の新規インストールは、scheduler-no-bind-address ルールで失敗していました。今回の更新では、パラメーターが削除されたので、OpenShift Container Platform の新しいバージョンでは scheduler-no-bind-address ルールが無効になりました。(OCPBUGS-8347)

5.2.15. OpenShift Compliance Operator 1.0.0

OpenShift Compliance Operator 1.0.0 には、以下のアドバイザリーを利用できます。

5.2.15.1. 新機能および機能拡張

5.2.15.2. バグ修正

  • この更新前は、compliance_operator_compliance_scan_error_total メトリックには、エラーメッセージごとに異なる値を持つ ERROR ラベルがありました。この更新により、compliance_operator_compliance_scan_error_total メトリックの値は増加しません。(OCPBUGS-1803)
  • この更新前は、ocp4-api-server-audit-log-maxsize ルールにより FAIL 状態が発生していました。この更新により、エラーメッセージがメトリックから削除され、ベストプラクティスに従ってメトリックのカーディナリティが減少しました。(OCPBUGS-7520)
  • この更新前は、rhcos4-enable-fips-mode ルールの説明が分かりにくく、インストール後に FIPS を有効化できるという誤解を招くものでした。この更新により、rhcos4-enable-fips-mode ルールの説明で、インストール時に FIPS を有効化する必要があることを明確に示されました。(OCPBUGS-8358)

5.2.16. OpenShift Compliance Operator 0.1.61

OpenShift Compliance Operator 0.1.61 には、以下のアドバイザリーを利用できます。

5.2.16.1. 新機能および機能拡張

  • Compliance Operator は、スキャナー Pod のタイムアウト設定をサポートするようになりました。タイムアウトは ScanSetting オブジェクトで指定されます。スキャンがタイムアウト内に完了しない場合、スキャンは最大再試行回数に達するまで再試行します。詳細は、ScanSetting タイムアウトの設定 を参照してください。

5.2.16.2. バグ修正

  • 今回の更新以前は、Compliance Operator は必要な変数を入力として修復していました。変数が設定されていない修復はクラスター全体に適用され、修復が正しく適用された場合でも、ノードがスタックしていました。今回の更新により、Compliance Operator は、修復のために TailoredProfile を使用して変数を提供する必要があるかどうかを検証します。(OCPBUGS-3864)
  • 今回の更新以前は、ocp4-kubelet-configure-tls-cipher-suites の手順が不完全であるため、ユーザーはクエリーを手動で調整する必要がありました。今回の更新により、ocp4-kubelet-configure-tls-cipher-suites で提供されるクエリーが実際の結果を返し、監査ステップを実行します。(OCPBUGS-3017)
  • 今回の更新以前は、システム予約パラメーターが kubelet 設定ファイルで生成されず、Compliance Operator はマシン設定プールの一時停止に失敗していました。今回の更新により、Compliance Operator は、マシン設定プールの評価時にシステム予約パラメーターを省略します。(OCPBUGS-4445)
  • 今回の更新以前は、ComplianceCheckResult オブジェクトに正しい説明がありませんでした。今回の更新により、Compliance Operator は、ルールの説明から ComplianceCheckResult 情報を取得します。(OCPBUGS-4615)
  • この更新前は、Compliance Operator はマシン設定の解析時に空の kubelet 設定ファイルをチェックしませんでした。その結果、Compliance Operator はパニックになり、クラッシュします。今回の更新により、Compliance Operator は kubelet 設定データ構造の改善されたチェックを実装し、完全にレンダリングされた場合にのみ続行します。(OCPBUGS-4621)
  • この更新前は、Compliance Operator がマシン設定プール名と猶予期間に基づいて kubelet の退避に対する修復を生成していました。そのため、1 つの退避ルールに対して複数の修復が発生していました。この更新により、Compliance Operator は 1 つのルールに対してすべての修復を適用するようになりました。(OCPBUGS-4338)
  • この更新の前に、デフォルト以外の MachineConfigPoolTailoredProfile を使用する ScanSettingBinding を作成しようとすると、ScanSettingBindingFailed としてマークされるというリグレッションが発生していました。今回の更新で、機能が復元され、TailoredProfile を使用してカスタム ScanSettingBinding が正しく実行されるようになりました。(OCPBUGS-6827)
  • 今回の更新以前は、一部の kubelet 設定パラメーターにデフォルト値がありませんでした。今回の更新により、次のパラメーターにデフォルト値が含まれます (OCPBUGS-6708)。

    • ocp4-cis-kubelet-enable-streaming-connections
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-available
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-inodesfree
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-memory-available
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-nodefs-available
  • 今回の更新以前は、kubelet の実行に必要なパーミッションが原因で、selinux_confinement_of_daemons ルールが kubelet で実行できませんでした。今回の更新で、selinux_confinement_of_daemons ルールが無効になります。(OCPBUGS-6968)

5.2.17. OpenShift Compliance Operator 0.1.59

OpenShift Compliance Operator 0.1.59 については、次のアドバイザリーが利用できます。

5.2.17.1. 新機能および機能拡張

  • Compliance Operator は、ppc64le アーキテクチャーで Payment Card Industry Data Security Standard (PCI-DSS) ocp4-pci-dss および ocp4-pci-dss-node プロファイルをサポートするようになりました。

5.2.17.2. バグ修正

  • 以前は、Compliance Operator は ppc64le などの異なるアーキテクチャーで Payment Card Industry Data Security Standard (PCI DSS) ocp4-pci-dss および ocp4-pci-dss-node プロファイルをサポートしていませんでした。Compliance Operator は、ppc64le アーキテクチャーで ocp4-pci-dss および ocp4-pci-dss-node プロファイルをサポートするようになりました。(OCPBUGS-3252)
  • 以前は、バージョン 0.1.57 への最近の更新後、rerunner サービスアカウント (SA) はクラスターサービスバージョン (CSV) によって所有されなくなり、Operator のアップグレード中に SA が削除されました。現在、CSV は 0.1.59 で rerunner SA を所有しており、以前のバージョンからアップグレードしても SA が欠落することはありません。(OCPBUGS-3452)

5.2.18. OpenShift Compliance Operator 0.1.57

OpenShift Compliance Operator 0.1.57 には、以下のアドバイザリーを利用できます。

5.2.18.1. 新機能および機能拡張

  • KubeletConfig チェックが Node から Platform タイプに変更されました。KubeletConfig は、KubeletConfig のデフォルト設定を確認します。設定ファイルは、すべてのノードからノードプールごとに 1 つの場所に集約されます。デフォルトの設定値をもとにした KubeletConfig ルールの評価 を参照してください。
  • ScanSetting カスタムリソースでは、scanLimits 属性を使用して、スキャナー Pod のデフォルトの CPU およびメモリー制限をオーバーライドできるようになりました。詳細は、Compliance Operator のリソース制限の引き上げ を参照してください。
  • PriorityClass オブジェクトは ScanSetting で設定できるようになりました。これにより、Compliance Operator が優先され、クラスターがコンプライアンス違反になる可能性が最小限に抑えられます。詳細は、ScanSetting スキャンの PriorityClass の設定 を参照してください。

5.2.18.2. バグ修正

  • 以前のバージョンでは、Compliance Operator は通知をデフォルトの openshift-compliance namespace にハードコーディングしていました。Operator がデフォルト以外の namespace にインストールされている場合、通知は予想通りに機能しませんでした。今回のリリースより、通知はデフォルト以外の openshift-compliance namespace で機能するようになりました。(BZ#2060726)
  • 以前のバージョンでは、Compliance Operator は kubelet オブジェクトによって使用されるデフォルト設定を評価できず、不正確な結果と誤検出が発生していました。この新機能 は kubelet 設定を評価し、正確に報告するようになりました。(BZ#2075041)
  • 以前は、Compliance Operator は、eventRecordQPS の値がデフォルト値よりも大きいため、自動修復の適用後に FAIL 状態で ocp4-kubelet-configure-event-creation ルールを報告していました。ocp4-kubelet-configure-event-creation ルール修復はデフォルト値を設定し、ルールが正しく適用されるようになりました。(BZ#2082416)
  • ocp4-configure-network-policies ルールでは、効果的に実行するために手動の介入が必要です。新しい説明的な指示とルールの更新により、Calico CNI を使用するクラスターに対する ocp4-configure-network-policies ルールの適用性が向上します。(BZ#2091794)
  • 以前は、スキャン設定で debug=true オプションを使用すると、Compliance Operator がインフラストラクチャーのスキャンに使用される Pod をクリーンアップしませんでした。これにより、ScanSettingBinding を削除した後でも Pod がクラスターに残されました。現在、ScanSettingBinding が削除されると、Pod は常に削除されます (BZ#2092913)。
  • 以前のバージョンでは、Compliance Operator は古いバージョンの operator-sdk コマンドを使用しており、非推奨の機能についてアラートが発生していました。現在、operator-sdk コマンドの更新バージョンが含まれており、廃止された機能に関するアラートが発生することはなくなりました。(BZ#2098581)
  • 以前のバージョンでは、Compliance Operator は kubelet とマシン設定の関係を判別できない場合に、修復の適用に失敗しました。Compliance Operator はマシン設定の処理を改善し、kubelet 設定がマシン設定のサブセットであるかどうかを判別できるようになりました。(BZ#2102511)
  • 以前のリリースでは、ocp4-cis-node-master-kubelet-enable-cert-rotation のルールで成功基準が適切に記述されていませんでした。その結果、RotateKubeletClientCertificate の要件が不明確でした。今回のリリースでは、ocp4-cis-node-master-kubelet-enable-cert-rotation のルールで、kubelet 設定ファイルにある設定に関係なく正確にレポートされるようになりました。(BZ#2105153)
  • 以前のリリースでは、アイドルストリーミングタイムアウトをチェックするルールでデフォルト値が考慮されなかったため、ルールレポートが正確ではありませんでした。今回のリリースより、チェックがより厳密に行われるようになり、デフォルトの設定値に基づいて結果の精度が向上しました。(BZ#2105878)
  • 以前のバージョンでは、Compliance Operator は Ignition 仕様なしでマシン設定を解析する際に API リソースを取得できず、api-check-pods プロセスがクラッシュしていました。現在は、Compliance Operator は Ignition 仕様を持たないマシン設定プールを正しく処理します。(BZ#2117268)
  • 以前のリリースでは、modprobe 設定の値が一致しないことが原因で、修復の適用後に modprobe 設定を評価するルールが失敗することがありました。今回のリリースより、チェックおよび修復の modprobe 設定に同じ値が使用されるようになり、結果の一貫性が保たれるようになりました。(BZ#2117747)

5.2.18.3. 非推奨

  • Install into all namespaces in the cluster を指定するか、WATCH_NAMESPACES 環境変数を "" に設定しても、すべての namespace に設定が適用されなくなりました。Compliance Operator のインストール時に指定されていない namespace にインストールされた API リソースは動作しなくなります。API リソースでは、選択した namespace またはデフォルトで openshift-compliance namespace を作成する必要がある場合があります。今回の変更により、Compliance Operator のメモリー使用量が改善されます。

5.2.19. OpenShift Compliance Operator 0.1.53

OpenShift Compliance Operator 0.1.53 については、次のアドバイザリーが利用できます。

5.2.19.1. バグ修正

  • 以前は、ocp4-kubelet-enable-streaming-connections ルールに誤った変数比較が含まれていたため、スキャン結果が誤検出されていました。現在、Compliance Operator は、streamingConnectionIdleTimeout を設定するときに正確なスキャン結果を提供します。(BZ#2069891)
  • 以前は、/etc/openvswitch/conf.db のグループ所有権が IBM Z® アーキテクチャーで正しくなかったため、ocp4-cis-node-worker-file-groupowner-ovs-conf-db のチェックが失敗していました。現在、このチェックは IBM Z® アーキテクチャーシステムでは NOT-APPLICABLE とマークされています。(BZ#2072597)
  • 以前は、デプロイメント内の Security Context Constraints (SCC) ルールに関するデータが不完全なため、ocp4-cis-scc-limit-container-allowed-capabilities ルールが FAIL 状態で報告されていました。現在は、結果は MANUAL ですが、これは、人間の介入を必要とする他のチェックと一致しています。(BZ#2077916)
  • 以前は、以下のルールが API サーバーおよび TLS 証明書とキーの追加の設定パスを考慮していなかったため、証明書とキーが適切に設定されていても失敗が報告されていました。

    • ocp4-cis-api-server-kubelet-client-cert
    • ocp4-cis-api-server-kubelet-client-key
    • ocp4-cis-kubelet-configure-tls-cert
    • ocp4-cis-kubelet-configure-tls-key

    これで、ルールは正確にレポートし、kubelet 設定ファイルで指定されたレガシーファイルパスを監視します。(BZ#2079813)

  • 以前は、content_rule_oauth_or_oauthclient_inactivity_timeout ルールは、タイムアウトのコンプライアンスを評価するときに、デプロイメントによって設定された設定可能なタイムアウトを考慮していませんでした。その結果、タイムアウトが有効であってもルールが失敗していました。現在、Compliance Operator は、var_oauth_inactivity_timeout 変数を使用して、有効なタイムアウトの長さを設定しています。(BZ#2081952)
  • 以前は、Compliance Operator は、特権使用に適切にラベル付けされていない namespace に対して管理者権限を使用していたため、Pod のセキュリティーレベル違反に関する警告メッセージが表示されていました。現在、Compliance Operator は、適切な namespace ラベルと権限調整を行い、権限に違反することなく結果にアクセスできるようになっています。(BZ#2088202)
  • 以前は、rhcos4-high-master-sysctl-kernel-yama-ptrace-scope および rhcos4-sysctl-kernel-core-pattern に自動修復を適用すると、それらのルールが修復されても、その後のスキャン結果で失敗することがありました。現在、修復が適用された後でも、ルールは PASS を正確に報告します。(BZ#2094382)
  • 以前は、Compliance Operator は、メモリー不足の例外が原因で CrashLoopBackoff 状態で失敗していました。現在では、Compliance Operator は、メモリー内の大規模なマシン設定データセットを処理し、正しく機能するように改良されました。(BZ#2094854)

5.2.19.2. 既知の問題

  • ScanSettingBinding オブジェクト内で "debug":true が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
    Copy to Clipboard Toggle word wrap

    (BZ#2092913)

5.2.20. OpenShift Compliance Operator 0.1.52

OpenShift Compliance Operator 0.1.52 については、次のアドバイザリーが利用できます。

5.2.20.1. 新機能および機能拡張

5.2.20.2. バグ修正

  • 以前は、DAC_OVERRIDE 機能が削除されているセキュリティー環境でのマウントパーミッションの問題が原因で、OpenScap コンテナーがクラッシュしていました。今回は、実行可能なマウントパーミッションがすべてのユーザーに適用されるようになりました。(BZ#2082151)
  • 以前は、コンプライアンスルール ocp4-configure-network-policiesMANUAL として設定できました。今回は、コンプライアンスルール ocp4-configure-network-policiesAUTOMATIC に設定されるようになりました。(BZ#2072431)
  • 以前は、Compliance Operator のスキャン Pod はスキャン後に削除されないため、Cluster Autoscaler はスケールダウンできませんでした。今回は、デバッグ目的で明示的に保存されていない限り、Pod はデフォルトで各ノードから削除されるようになりました。(BZ#2075029)
  • 以前は、Compliance Operator を KubeletConfig に適用すると、マシン設定プールの一時停止が早すぎてノードが NotReady 状態になることがありました。今回は、マシン設定プールは停止されず、ノードが正常に機能するようになりました。(BZ#2071854)
  • 以前のバージョンでは、Machine Config Operator は最新のリリースで url-encoded コードではなく base64 を使用していたため、Compliance Operator の修復が失敗していました。Compliance Operator は、base64 および url-encoded マシン設定コードの両方を処理するようにエンコーディングをチェックし、修復が適切に実行されるようになりました。(BZ#2082431)

5.2.20.3. 既知の問題

  • ScanSettingBinding オブジェクト内で "debug":true が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
    Copy to Clipboard Toggle word wrap

    (BZ#2092913)

5.2.21. OpenShift Compliance Operator 0.1.49

OpenShift Compliance Operator 0.1.49 については、次のアドバイザリーが利用できます。

5.2.21.1. 新機能および機能拡張

  • Compliance Operator は、次のアーキテクチャーでサポートされるようになりました。

    • IBM Power®
    • IBM Z®
    • IBM® LinuxONE

5.2.21.2. バグ修正

  • 以前は、openshift-compliance コンテンツには、ネットワークタイプのプラットフォーム固有のチェックが含まれていませんでした。その結果、OVN および SDN 固有のチェックは、ネットワーク設定に基づいて not-applicable ではなく、failed したものとして表示されます。現在、新しいルールにはネットワークルールのプラットフォームチェックが含まれているため、ネットワーク固有のチェックをより正確に評価できます。(BZ#1994609)
  • 以前は、ocp4-moderate-routes-protected-by-tls ルールは TLS 設定を誤ってチェックしていたため、接続がセキュアな SSL/TLS プロトコルであっても、ルールがチェックに失敗していました。現在、このチェックでは、ネットワークガイダンスおよびプロファイルの推奨事項と一致する TLS 設定が適切に評価されます。(BZ#2002695)
  • 以前は、ocp-cis-configure-network-policies-namespace は、namespaces を要求するときにページネーションを使用していました。これにより、デプロイメントで 500 を超える namespaces のリストが切り捨てられたため、ルールが失敗しました。今回のバージョンでは、namespace の全リストが必要になり、namespace が 500 以上ある場合でも、設定済みのネットワークポリシーをチェックするルールが機能するようになりました。(BZ#2038909)
  • 以前は、sshd jinja マクロを使用した修復は、特定の sshd 設定にハードコーディングされていました。その結果、設定がルールがチェックしているコンテンツと一致せず、チェックが失敗していました。これで、sshd 設定がパラメーター化され、ルールが正常に適用されます。(BZ#2049141)
  • 以前は、ocp4-cluster-version-operator-verify-integrity が、常に Cluter Version Operator (CVO) 履歴の最初のエントリーをチェックしていました。その結果、後続の OpenShift Container Platform バージョンが検証される状況ではアップグレードが失敗します。これで、ocp4-cluster-version-operator-verify-integrity のコンプライアンスチェック結果は、検証済みバージョンを検出でき、CVO 履歴で正確になります。(BZ#2053602)
  • 以前は、ocp4-api-server-no-adm-ctrl-plugins-disabled ルールは、空のアドミッションコントローラープラグインのリストをチェックしませんでした。その結果、すべてのアドミッションプラグインが有効になっている場合でも、ルールは常に失敗します。今回のリリースでは、ocp4-api-server-no-adm-ctrl-plugins-disabled ルールのチェックが強力になり、すべての受付コントローラープラグインを有効にすると、問題なく成功するようになりました。(BZ#2058631)
  • 以前は、スキャンには Linux ワーカーノードに対して実行するためのプラットフォームチェックが含まれていませんでした。その結果、Linux ベースではないワーカーノードに対してスキャンを実行すると、スキャンループが終了することはありませんでした。今回のリリースでは、スキャンは、プラットフォームのタイプとラベルに基づいて適切にスケジュールされ、正確に実行されます。(BZ#2056911)

5.2.22. OpenShift Compliance Operator 0.1.48

OpenShift Compliance Operator 0.1.48 には、以下のアドバイザリーを利用できます。

5.2.22.1. バグ修正

  • 以前は、拡張された Open Vulnerability and Assessment Language (OVAL) 定義に関連する一部のルールの checkTypeNone でした。これは、Compliance Operator が、ルールを解析するときに拡張 OVAL 定義を処理していなかったためです。この更新により、拡張 OVAL 定義のコンテンツが解析され、これらのルールの checkTypeNode または Platform になります。(BZ#2040282)
  • 以前は、KubeletConfig 用に手動で作成された MachineConfig オブジェクトにより、KubeletConfig オブジェクトが修復用に生成されなくなり、修復が Pending 状態のままになりました。このリリースでは、KubeletConfig 用に手動で作成された MachineConfig オブジェクトがあるかどうかに関係なく、修復によって KubeletConfig オブジェクトが作成されます。その結果、KubeletConfig の修正が期待どおりに機能するようになりました。(BZ#2040401)

5.2.23. OpenShift Compliance Operator 0.1.47

OpenShift Compliance Operator 0.1.47 には、以下のアドバイザリーを利用できます。

5.2.23.1. 新機能および機能拡張

  • Compliance Operator は、Payment Card Industry Data Security Standard (PCI DSS) の次のコンプライアンスベンチマークをサポートするようになりました。

    • ocp4-pci-dss
    • ocp4-pci-dss-node
  • FedRAMP の中程度の影響レベルの追加のルールと修正が、OCP4-moderate、OCP4-moderate-node、および rhcos4-moderate プロファイルに追加されます。
  • KubeletConfig の修正がノードレベルのプロファイルで利用できるようになりました。

5.2.23.2. バグ修正

  • 以前は、クラスターが OpenShift Container Platform 4.6 以前を実行していた場合、中程度のプロファイルでは USBGuard 関連のルールの修正が失敗していました。これは、Compliance Operator によって作成された修正が、ドロップインディレクトリーをサポートしていない古いバージョンの USBGuard に基づいていたためです。現在、OpenShift Container Platform 4.6 を実行しているクラスターでは、USBGuard 関連のルールの無効な修復は作成されません。クラスターが OpenShift Container Platform 4.6 を使用している場合は、USBGuard 関連のルールの修正を手動で作成する必要があります。

    さらに、修正は、最小バージョン要件を満たすルールに対してのみ作成されます。(BZ#1965511)

  • 以前のリリースでは、修正をレンダリングする場合には、Compliance Operator は、その修正が適切に設定されているかを、厳密すぎる正規表現を使用して確認していました。その結果、sshd_config をレンダリングするような一部の修正は、正規表現チェックに合格しないため、作成されませんでした。正規表現は不要であることが判明し、削除されました。修復が正しくレンダリングされるようになりました。(BZ#2033009)

5.2.24. OpenShift Compliance Operator 0.1.44

OpenShift Compliance Operator 0.1.44 には、以下のアドバイザリーを利用できます。

5.2.24.1. 新機能および機能拡張

  • このリリースでは、strictNodeScan オプションが ComplianceScanComplianceSuite、および ScanSetting CR に追加されました。このオプションのデフォルトは true で、これは以前の動作と一致します。ノードでスキャンをスケジュールできなかった場合にエラーが発生しました。このオプションを false に設定すると、Compliance Operator は、スキャンのスケジュールについてより寛容になります。エフェメラルノードのある環境では、strictNodeScan 値を false に設定できます。これにより、クラスター内の一部のノードがスケジューリングに使用できない場合でも、コンプライアンススキャンを続行できます。
  • ScanSetting オブジェクトの nodeSelector 属性と tolerations 属性を設定することにより、結果サーバーのワークロードをスケジュールするために使用されるノードをカスタマイズできるようになりました。これらの属性は、PV ストレージボリュームをマウントし、生の Asset Reporting Format (ARF) 結果を格納するために使用される Pod である ResultServer Pod を配置するために使用されます。以前は、nodeSelector パラメーターおよび tolerations パラメーターは、デフォルトでコントロールプレーンノードの 1 つを選択し、node-role.kubernetes.io/master taint を許容していました。これは、コントロールプレーンノードが PV をマウントすることを許可されていない環境では機能しませんでした。この機能は、ノードを選択し、それらの環境で異なるテイントを許容する方法を提供します。
  • Compliance Operator は、KubeletConfig オブジェクトを修正できるようになりました。
  • エラーメッセージを含むコメントが追加され、コンテンツ開発者がクラスター内に存在しないオブジェクトとフェッチできないオブジェクトを区別できるようになりました。
  • ルールオブジェクトには、checkType および description の 2 つの新しい属性が含まれるようになりました。これらの属性を使用すると、ルールがノードチェックとプラットフォームチェックのどちらに関連しているかを判断したり、ルールの機能を確認したりできます。
  • 今回の機能拡張により、既存のプロファイルを拡張して調整されたプロファイルを作成する必要があるという要件がなくなります。これは、TailoredProfile CRD の extends フィールドが必須ではなくなったことを意味します。これで、ルールオブジェクトのリストを選択して、調整されたプロファイルを作成できます。compliance.openshift.io/product-type: アノテーションを設定するか、TailoredProfile CR の -node 接尾辞を設定して、プロファイルをノードに適用するかプラットフォームに適用するかを選択する必要があることに注意してください。
  • このリリースでは、Compliance Operator は、テイントに関係なく、すべてのノードでスキャンをスケジュールできるようになりました。以前は、スキャン Pod は node-role.kubernetes.io/master taint のみを許容していました。つまり、テイントのないノードで実行するか、node-role.kubernetes.io/master テイントのあるノードでのみ実行していました。ノードにカスタムテイントを使用するデプロイメントでは、これにより、それらのノードでスキャンがスケジュールされませんでした。現在、スキャン Pod はすべてのノードのテイントを許容します。
  • このリリースでは、Compliance Operator は、次の North American Electric Reliability Corporation (NERC) のセキュリティープロファイルをサポートしています。

    • ocp4-nerc-cip
    • ocp4-nerc-cip-node
    • rhcos4-nerc-cip
  • このリリースでは、Compliance Operator は、NIST 800-53 Moderate-Impact Baseline for the Red Hat OpenShift - Node level, ocp4-moderate-node セキュリティープロファイルをサポートします。

5.2.24.2. テンプレートと変数の使用

  • このリリースでは、修復テンプレートで複数値の変数を使用できるようになりました。
  • この更新により、Compliance Operator は、コンプライアンスプロファイルで設定された変数に基づいて修正を変更できます。これは、タイムアウト、NTP サーバーのホスト名などのデプロイメント固有の値を含む修復に役立ちます。さらに、ComplianceCheckResult オブジェクトは、チェックが使用した変数をリストするラベル compliance.openshift.io/check-has-value を使用するようになりました。

5.2.24.3. バグ修正

  • 以前は、スキャンの実行中に、Pod のスキャナーコンテナーの 1 つで予期しない終了が発生しました。このリリースでは、Compliance Operator は、クラッシュを回避するために最新の OpenSCAP バージョン 1.3.5 を使用します。
  • 以前は、autoReplyRemediations を使用して修復を適用すると、クラスターノードの更新がトリガーされていました。一部の修復に必要な入力変数がすべて含まれていない場合、これは中断されました。これで、修復に 1 つ以上の必要な入力変数が欠落している場合、NeedsReview の状態が割り当てられます。1 つ以上の修復が NeedsReview 状態にある場合、マシン設定プールは一時停止されたままになり、必要なすべての変数が設定されるまで修復は適用されません。これにより、ノードの中断を最小限に抑えることができます。
  • Prometheus メトリックに使用される RBAC Role と Role Binding が 'ClusterRole' と 'ClusterRoleBinding' に変更なり、カスタマイズなしで監視が機能するようになりました。
  • 以前は、プロファイルの解析中にエラーが発生した場合、ルールまたは変数オブジェクトが削除され、プロファイルから削除されていました。これで、解析中にエラーが発生した場合、profileparser はオブジェクトに一時的なアノテーションを付けて、解析が完了するまでオブジェクトが削除されないようにします。(BZ#1988259)
  • 以前のバージョンでは、調整されたプロファイルにタイトルまたは説明がない場合、エラーが発生しました。XCCDF 標準では、調整されたプロファイルのタイトルと説明が必要なため、タイトルと説明を TailoredProfile CR で設定する必要があります。
  • 以前は、調整されたプロファイルを使用する場合、特定の選択セットのみを使用して TailoredProfile 変数値を設定できました。この制限がなくなり、TailoredProfile 変数を任意の値に設定できるようになりました。

5.2.25. Compliance Operator 0.1.39 リリースノート

OpenShift Compliance Operator 0.1.39 については、次のアドバイザリーが利用できます。

5.2.25.1. 新機能および機能拡張

  • 以前は、Compliance Operator は、Payment Card Industry Data Security Standard (PCI DSS) 参照を解析できませんでした。現在、Operator は、PCI DSS プロファイルで提供されるコンプライアンスコンテンツを解析できるようになりました。
  • 以前は、Compliance Operator は、中程度のプロファイルで AU-5 制御のルールを実行できませんでした。これで、Prometheusrules.monitoring.coreos.com オブジェクトを読み取り、中程度のプロファイルで AU-5 コントロールを扱うルールを実行できるように、Operator にアクセス許可が追加されました。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat