5.2. Compliance Operator リリースノート
Compliance Operator を使用すると、OpenShift Container Platform 管理者はクラスターの必要なコンプライアンス状態を記述し、存在するギャップやそれらを修復する方法に関する概要を提供します。
これらのリリースノートは、OpenShift Container Platform での Compliance Operator の開発を追跡します。
Compliance Operator の概要は、Understanding the Compliance Operator を参照してください。
最新リリースにアクセスするには、コンプライアンス Operator の更新 を参照してください。
すべての Red Hat 製品のコンプライアンスサポートの詳細は、製品コンプライアンス を参照してください。
5.2.1. OpenShift Compliance Operator 1.6.0
OpenShift Compliance Operator 1.6.0 には、以下のアドバイザリーが利用できます。
5.2.1.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 でサポートされているプロファイルが含まれています。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
-
x86、ppc64le、およびs390xアーキテクチャーにインストールされた Compliance Operator で、must-gather拡張が利用できるようになりました。must-gatherツールにより、重要な設定の詳細が Red Hat Customer Support チームと Engineering チームに提供されます。詳細は、Compliance Operator の must-gather ツールの使用 を参照してください。
5.2.1.2. バグ修正
-
このリリース前は、
ocp4-route-ip-whitelistルールの誤解を招くような説明により誤解が生じ、誤った設定が発生する可能性がありました。この更新により、ルールがより明確に定義されるようになりました。(CMP-2485) -
以前は、
DONEステータスのComplianceScanのすべてのComplianceCheckResultsのレポートが不完全でした。この更新により、ステータスがDONEであるComplianceScanのComplianceCheckResultsの合計数を報告するためのアノテーションが追加されました。(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.2. OpenShift Compliance Operator 1.5.1
OpenShift Compliance Operator 1.5.1 には、以下のアドバイザリーが利用できます。
5.2.3. OpenShift Compliance Operator 1.5.0
OpenShift Compliance Operator 1.5.0 には、以下のアドバイザリーが利用できます。
5.2.3.1. 新機能および機能拡張
5.2.3.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.4. OpenShift Compliance Operator 1.4.1
OpenShift Compliance Operator 1.4.1 には、以下のアドバイザリーが利用できます。
5.2.4.1. 新機能および機能拡張
5.2.4.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.5. OpenShift Compliance Operator 1.4.0
OpenShift Compliance Operator 1.4.0 には、以下のアドバイザリーが利用できます。
5.2.5.1. 新機能および機能拡張
-
この更新により、デフォルトの
workerおよびmasterノードプール以外のカスタムノードプールを使用するクラスターで、Compliance Operator がそのノードプールの設定ファイルを確実に集約するための追加変数を指定する必要がなくなりました。 -
ユーザーは、
ScanSetting.suspend属性をTrueに設定することで、スキャンスケジュールを一時停止できるようになりました。これにより、ユーザーはScanSettingBindingを削除して再作成することなく、スキャンスケジュールを一時停止し、再アクティブ化できます。そのため、メンテナンス期間中のスキャンスケジュールを簡単に一時停止できます。(CMP-2123) -
Compliance Operator は、
Profileカスタムリソースでオプションのversion属性をサポートするようになりました。(CMP-2125) -
Compliance Operator は、
ComplianceRulesのプロファイル名をサポートするようになりました。(CMP-2126) -
このリリースでは、
cronjobAPI が改良された Compliance Operator の互換性を使用できます。(CMP-2310)
5.2.5.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.6. OpenShift Compliance Operator 1.3.1
OpenShift Compliance Operator 1.3.1 には、以下のアドバイザリーが利用できます。
この更新プログラムは、基になる依存関係の CVE に対処します。
重要
OpenShift Container Platform クラスターをバージョン 4.14 以降に更新する前に、Compliance Operator をバージョン 1.3.1 以降に更新することが推奨されます。
5.2.6.1. 新機能および機能拡張
Compliance Operator は、FIPS モードで実行されている OpenShift Container Platform クラスターにインストールして使用できます。
重要クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された RHEL コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。
5.2.6.2. 既知の問題
- Windows ノードがコンプライアンススキャンでスキップされないため、Windows ノードを含むクラスターでは、自動修復の適用後に一部のルールが失敗します。スキャン時に Windows ノードをスキップする必要があるため、これは想定される結果とは異なります。(OCPBUGS-7355)
5.2.7. OpenShift Compliance Operator 1.3.0
OpenShift Compliance Operator 1.3.0 には、以下のアドバイザリーが利用できます。
5.2.7.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.8. OpenShift Compliance Operator 1.2.0
OpenShift Compliance Operator 1.2.0 には、以下のアドバイザリーが利用できます。
5.2.8.1. 新機能および機能拡張
CIS OpenShift Container Platform 4 Benchmark v1.4.0 プロファイルがプラットフォームおよびノードアプリケーションで利用できるようになりました。CIS OpenShift Container Platform v4 ベンチマークを見つけるには、CIS ベンチマーク に移動し、最新の CIS ベンチマークをダウンロード をクリックします。ここでベンチマークをダウンロードするために登録できます。
重要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.8.2. 既知の問題
- CIS OpenShift Container Platform 4 Benchmark v1.4.0 プロファイルを使用する場合、一部のコントロールは OpenShift Container Platform よりも厳格な CIS プロファイルのパーミッションにより失敗する可能性があります。詳細は、ソリューション記事 #7024725 を参照してください。
5.2.9. OpenShift Compliance Operator 1.1.0
OpenShift Compliance Operator 1.1.0 には、以下のアドバイザリーを利用できます。
5.2.9.1. 新機能および機能拡張
-
ComplianceScanカスタムリソース定義 (CRD) ステータスで開始および終了のタイムスタンプが利用できるようになりました。 -
Compliance Operator は、
サブスクリプションファイルを作成することで、OperatorHub を使用してホストされたコントロールプレーンにデプロイメントできるようになりました。詳細は、ホストされたコントロールプレーンへのCompliance Operator のインストール を参照してください。
5.2.9.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
-
この更新前は、チェックの精度とルールの指示が不明確でした。今回の更新後、次の
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
-
-
今回の更新以前は、
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.10. OpenShift Compliance Operator 1.0.0
OpenShift Compliance Operator 1.0.0 には、以下のアドバイザリーを利用できます。
5.2.10.1. 新機能および機能拡張
-
Compliance Operator は stable になり、リリースチャネルは
stableにアップグレードされました。将来のリリースは Semantic Versioning に従います。最新リリースにアクセスするには、コンプライアンス Operator の更新 を参照してください。
5.2.10.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.11. OpenShift Compliance Operator 0.1.61
OpenShift Compliance Operator 0.1.61 には、以下のアドバイザリーを利用できます。
5.2.11.1. 新機能および機能拡張
-
Compliance Operator は Scanner Pod のタイムアウト設定をサポートするようになりました。タイムアウトは
ScanSettingオブジェクトで指定されます。スキャンがタイムアウト内に完了しない場合、スキャンは最大再試行回数に達するまで再試行します。詳細は、ScanSetting タイムアウトの設定 を参照してください。
5.2.11.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 エビクションの修復を生成していたため、単一のエビクションルールの複数の修復が発生していました。今回の更新により、Compliance Operator は単一のルールに対してすべての修復を適用するようになりました。(OCPBUGS-4338)
-
この更新の前に、デフォルト以外の
MachineConfigPoolでTailoredProfileを使用するScanSettingBindingを作成しようとすると、ScanSettingBindingがFailedとしてマークされるというリグレッションが発生していました。今回の更新で、機能が復元され、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.12. OpenShift Compliance Operator 0.1.59
OpenShift Compliance Operator 0.1.59 には、以下のアドバイザリーが利用できます。
5.2.12.1. 新機能および機能拡張
-
Compliance Operator は、
ppc64leアーキテクチャーで Payment Card Industry Data Security Standard (PCI-DSS)ocp4-pci-dssおよびocp4-pci-dss-nodeプロファイルをサポートするようになりました。
5.2.12.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 でrerunnerSA を所有しており、以前のバージョンからアップグレードしても SA が欠落することはありません。(OCPBUGS-3452)
5.2.13. OpenShift Compliance Operator 0.1.57
OpenShift Compliance Operator 0.1.57 には、以下のアドバイザリーを利用できます。
5.2.13.1. 新機能および機能拡張
-
KubeletConfigチェックがNodeからPlatformタイプに変更されました。KubeletConfigは、KubeletConfigのデフォルト設定を確認します。設定ファイルは、すべてのノードからノードプールごとに 1 つの場所に集約されます。デフォルトの設定値をもとにしたKubeletConfigルールの評価 を参照してください。 -
ScanSettingカスタムリソースでは、scanLimits属性を使用して、スキャナー Pod のデフォルトの CPU およびメモリー制限をオーバーライドできるようになりました。詳細は、Compliance Operator リソース制限の増加 を参照してください。 -
PriorityClassオブジェクトはScanSettingで設定できるようになりました。これにより、Compliance Operator が優先され、クラスターがコンプライアンス違反になる可能性が最小限に抑えられます。詳細は、ScanSettingスキャンのPriorityClassの設定 を参照してください。
5.2.13.2. バグ修正
-
以前のバージョンでは、Compliance Operator は通知をデフォルトの
openshift-compliancenamespace にハードコーディングしていました。Operator がデフォルト以外の namespace にインストールされている場合、通知は予想通りに機能しませんでした。今回のリリースより、通知はデフォルト以外のopenshift-compliancenamespace で機能するようになりました。(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オプションを使用すると、インフラストラクチャーのスキャンに使用される 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 仕様が正しくない場合も Machine Config Pool を処理するようになりました。(BZ#2117268) -
以前のリリースでは、
modprobe設定の値が一致しないことが原因で、修復の適用後にmodprobe設定を評価するルールが失敗することがありました。今回のリリースより、チェックおよび修復のmodprobe設定に同じ値が使用されるようになり、結果の一貫性が保たれるようになりました。(BZ#2117747)
5.2.13.3. 非推奨
-
Install into all namespaces in the cluster を指定するか、
WATCH_NAMESPACES環境変数を""に設定しても、すべての namespace に設定が適用されなくなりました。Compliance Operator のインストール時に指定されていない namespace にインストールされた API リソースは動作しなくなります。API リソースでは、選択した namespace またはデフォルトでopenshift-compliancenamespace を作成する必要がある場合があります。今回の変更により、Compliance Operator のメモリー使用量が改善されます。
5.2.14. OpenShift Compliance Operator 0.1.53
OpenShift Compliance Operator 0.1.53 には、以下のアドバイザリーが利用できます。
5.2.14.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.14.2. 既知の問題
ScanSettingBindingオブジェクト内で"debug":trueが設定されている場合に、そのバインディングが削除されても、ScanSettingBindingオブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.2.15. OpenShift Compliance Operator 0.1.52
OpenShift Compliance Operator 0.1.52 には、以下のアドバイザリーが利用できます。
5.2.15.1. 新機能および機能拡張
- FedRAMP の SCAP プロファイル high が、OpenShift Container Platform 環境で使用できるようになりました。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
5.2.15.2. バグ修正
-
以前は、
DAC_OVERRIDE機能が削除されているセキュリティー環境でのマウントパーミッションの問題が原因で、OpenScapコンテナーがクラッシュしていました。今回は、実行可能なマウントパーミッションがすべてのユーザーに適用されるようになりました。(BZ#2082151) -
以前は、コンプライアンスルール
ocp4-configure-network-policiesをMANUALとして設定できました。今回は、コンプライアンスルールocp4-configure-network-policiesがAUTOMATICに設定されるようになりました。(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.15.3. 既知の問題
ScanSettingBindingオブジェクト内で"debug":trueが設定されている場合に、そのバインディングが削除されても、ScanSettingBindingオブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.2.16. OpenShift Compliance Operator 0.1.49
OpenShift Compliance Operator 0.1.49 には、以下のアドバイザリーが利用できます。
5.2.16.1. 新機能および機能拡張
Compliance Operator は、次のアーキテクチャーでサポートされるようになりました。
- IBM Power
- IBM Z
- IBM LinuxONE
5.2.16.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 バージョンオペレーター (CVO) 履歴の最初のエントリーをチェックしていました。その結果、{product-name} の後続のバージョンが検証される状況では、アップグレードは失敗します。これで、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.17. OpenShift Compliance Operator 0.1.48
OpenShift Compliance Operator 0.1.48 には、以下のアドバイザリーを利用できます。
5.2.17.1. バグ修正
-
以前は、拡張された Open Vulnerability and Assessment Language (OVAL) 定義に関連する一部のルールの
checkTypeはNoneでした。これは、Compliance Operator が、ルールを解析するときに拡張 OVAL 定義を処理していなかったためです。この更新により、拡張 OVAL 定義のコンテンツが解析され、これらのルールのcheckTypeがNodeまたはPlatformになります。(BZ#2040282) -
以前は、
KubeletConfig用に手動で作成されたMachineConfigオブジェクトにより、KubeletConfigオブジェクトが修復用に生成されなくなり、修復がPending状態のままになりました。このリリースでは、KubeletConfig用に手動で作成されたMachineConfigオブジェクトがあるかどうかに関係なく、修復によってKubeletConfigオブジェクトが作成されます。その結果、KubeletConfigの修正が期待どおりに機能するようになりました。(BZ#2040401)
5.2.18. OpenShift Compliance Operator 0.1.47
OpenShift Compliance Operator 0.1.47 には、以下のアドバイザリーを利用できます。
5.2.18.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.18.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.19. OpenShift Compliance Operator 0.1.44
OpenShift Compliance Operator 0.1.44 には、以下のアドバイザリーを利用できます。
5.2.19.1. 新機能および機能拡張
-
このリリースでは、
strictNodeScanオプションがComplianceScan、ComplianceSuite、およびScanSettingCR に追加されました。このオプションのデフォルトはtrueで、これは以前の動作と一致します。ノードでスキャンをスケジュールできなかった場合にエラーが発生しました。このオプションをfalseに設定すると、Compliance Operator は、スキャンのスケジュールについてより寛容になります。エフェメラルノードのある環境では、strictNodeScan値を false に設定できます。これにより、クラスター内の一部のノードがスケジューリングに使用できない場合でも、コンプライアンススキャンを続行できます。 -
ScanSettingオブジェクトのnodeSelector属性とtolerations属性を設定することにより、結果サーバーのワークロードをスケジュールするために使用されるノードをカスタマイズできるようになりました。これらの属性は、PV ストレージボリュームをマウントし、生の Asset Reporting Format (ARF) 結果を格納するために使用される Pod であるResultServerPod を配置するために使用されます。以前は、nodeSelectorパラメーターおよびtolerationsパラメーターは、デフォルトでコントロールプレーンノードの 1 つを選択し、node-role.kubernetes.io/master taintを許容していました。これは、コントロールプレーンノードが PV をマウントすることを許可されていない環境では機能しませんでした。この機能は、ノードを選択し、それらの環境で異なるテイントを許容する方法を提供します。 -
Compliance Operator は、
KubeletConfigオブジェクトを修正できるようになりました。 - エラーメッセージを含むコメントが追加され、コンテンツ開発者がクラスター内に存在しないオブジェクトとフェッチできないオブジェクトを区別できるようになりました。
-
ルールオブジェクトには、
checkTypeおよびdescriptionの 2 つの新しい属性が含まれるようになりました。これらの属性を使用すると、ルールがノードチェックとプラットフォームチェックのどちらに関連しているかを判断したり、ルールの機能を確認したりできます。 -
今回の機能拡張により、既存のプロファイルを拡張して調整されたプロファイルを作成する必要があるという要件がなくなります。これは、
TailoredProfileCRD のextendsフィールドが必須ではなくなったことを意味します。これで、ルールオブジェクトのリストを選択して、調整されたプロファイルを作成できます。compliance.openshift.io/product-type:アノテーションを設定するか、TailoredProfileCR の-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.19.2. テンプレートと変数の使用
- このリリースでは、修復テンプレートで複数値の変数を使用できるようになりました。
-
この更新により、Compliance Operator は、コンプライアンスプロファイルで設定された変数に基づいて修正を変更できます。これは、タイムアウト、NTP サーバーのホスト名などのデプロイメント固有の値を含む修復に役立ちます。さらに、
ComplianceCheckResultオブジェクトは、チェックが使用した変数をリストするラベルcompliance.openshift.io/check-has-valueを使用するようになりました。
5.2.19.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 標準では、調整されたプロファイルのタイトルと説明が必要なため、タイトルと説明を
TailoredProfileCR で設定する必要があります。 -
以前は、調整されたプロファイルを使用する場合、特定の選択セットのみを使用して
TailoredProfile変数値を設定できました。この制限がなくなり、TailoredProfile変数を任意の値に設定できるようになりました。
5.2.20. Compliance Operator 0.1.39 リリースノート
OpenShift Compliance Operator 0.1.39 には、以下のアドバイザリーが利用できます。
5.2.20.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 にアクセス許可が追加されました。
