第5章 Compliance Operator

5.1. Compliance Operator リリースノート

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

これらのリリースノートは、OpenShift Container Platform での Compliance Operator の開発を追跡します。

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

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

5.1.1. OpenShift Compliance Operator 1.2.0

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

RHBA-2023:4245 - OpenShift Compliance Operator の機能拡張の更新

5.1.1.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) の監査をさらに明確に scc-limit-container-allowed-capabilities ルールで利用できるようになりました。

5.1.2. OpenShift Compliance Operator 1.1.0

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

RHBA-2023:3630 - OpenShift Compliance Operator のバグ修正と機能拡張の更新

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

ComplianceScan カスタムリソース定義 (CRD) ステータスで開始および終了のタイムスタンプが利用できるようになりました。

5.1.2.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-on-oops
- 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.1.3. OpenShift Compliance Operator 1.0.0

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

RHBA-2023:1682 - OpenShift Compliance Operator バグ修正更新

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

Compliance Operator は stable になり、リリースチャネルは stable にアップグレードされました。将来のリリースは Semantic Versioning に従います。最新リリースにアクセスするには、Compliance Operator の更新を参照してください。

5.1.3.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.1.4. OpenShift Compliance Operator 0.1.61

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

RHBA-2023:0557 - OpenShift Compliance Operator bug fix update

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

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

5.1.4.2. バグ修正

今回の更新以前は、Compliance Operator は必要な変数を入力として修復していました。変数が設定されていない修復はクラスター全体に適用され、修復が正しく適用された場合でも、ノードがスタックしていました。今回の更新により、Compliance Operator は、修復のために TailoredProfile を使用して変数を提供する必要があるかどうかを検証します。(OCPBUGS-3864)
今回の更新以前は、ocp4-kubelet-configure-tls-cipher-suites の手順が不完全であるため、ユーザーはクエリーを手動で調整する必要がありました。今回の更新により、ocp4-kubelet-configure-tls-cipher-suites で提供されるクエリーが実際の結果を返し、監査ステップを実行します。(OCPBUGS-3017)
この更新の前に、settingRef 変数なしで作成された ScanSettingBinding オブジェクトは、適切なデフォルト値を使用しませんでした。今回の更新により、settingRef 変数のない ScanSettingBinding オブジェクトは default 値を使用します。(OCPBUGS-3420)
今回の更新以前は、システム予約パラメーターが 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)
今回の更新以前は、修復コンテンツに変更がなくても、再スキャンの実行後に、以前に Applied が Outdated とマークされていた可能性のある修復でスキャンを再実行していました。スキャンの比較では、修復メタデータが正しく考慮されませんでした。今回の更新により、修復は以前に生成された Applied ステータスを保持します。(OCPBUGS-6710)
この更新の前に、デフォルト以外の 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.1.5. OpenShift Compliance Operator 0.1.59

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

RHBA-2022:8538 - OpenShift Compliance Operator バグ修正更新

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

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

5.1.5.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)
0.1.57 では、Operator はポート 8080 でリッスンするコントローラーメトリックエンドポイントを開始しました。これにより、クラスター監視の予期されるポートが 8383 であるため、TargetDown アラートが発生しました。0.1.59 では、Operator は期待どおりにポート 8383 でリッスンするエンドポイントを開始します。(OCPBUGS-3097)

5.1.6. OpenShift Compliance Operator 0.1.57

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

RHBA-2022:6657 - OpenShift Compliance Operator バグ修正更新

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

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

5.1.6.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 オプションを使用すると、インフラストラクチャーのスキャンに使用される 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.1.6.3. 非推奨

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

5.1.7. OpenShift Compliance Operator 0.1.53

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

RHBA-2022:5537 - OpenShift Compliance Operator bug fix update

5.1.7.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)
以前は、デプロイメント内のセキュリティーコンテキスト制約 (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.1.7.2. 既知の問題

ScanSettingBinding オブジェクト内で debug:true が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。
```
$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
```
(BZ#2092913)

5.1.8. OpenShift Compliance Operator 0.1.52

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

RHBA-2022:4657 - OpenShift Compliance Operator bug fix update

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

FedRAMP の SCAP プロファイル high が、OpenShift Container Platform 環境で使用できるようになりました。詳細は、サポートされているコンプライアンスプロファイルを参照してください。

5.1.8.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.1.8.3. 既知の問題

ScanSettingBinding オブジェクト内で debug:true が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。
```
$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
```
(BZ#2092913)

5.1.9. OpenShift Compliance Operator 0.1.49

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

RHBA-2022:1148 - OpenShift Compliance Operator bug fix and enhancement update

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

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

5.1.9.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.1.10. OpenShift Compliance Operator 0.1.48

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

RHBA-2022:0416 - OpenShift Compliance Operator のバグ修正と機能拡張の更新

5.1.10.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.1.11. OpenShift Compliance Operator 0.1.47

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

RHBA-2022:0014 - OpenShift Compliance Operator のバグ修正と機能拡張の更新

5.1.11.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.1.11.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.1.12. OpenShift Compliance Operator 0.1.44

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

RHBA-2021:4530-OpenShift Compliance Operator のバグ修正と機能拡張の更新

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

このリリースでは、strictNodeScan オプションが ComplianceScan、ComplianceSuite、および 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.1.12.2. テンプレートと変数の使用

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

5.1.12.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.1.13. Compliance Operator 0.1.39 リリースノート

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

RHBA-2021:3214 - OpenShift Compliance Operator のバグ修正と機能拡張の更新

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

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

5.1.14. 関連情報

Compliance Operator について