検索
サポートコンソール開発者トライアルの開始お問い合わせ

5.2. Compliance Operator リリースノート

download PDF

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

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

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

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

5.2.1. OpenShift Compliance Operator 1.5.1

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

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

  • Compliance Operator には、Payment Card Industry Data Security Standard (PCI-DSS)バージョン 4 でサポートされるプロファイルが含まれるようになりました。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
  • Compliance Operator には、国防情報システム局セキュリティー技術実装ガイド(DISA STIG) V2R1 のサポートプロファイルが含まれるようになりました。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
  • must-gather 拡張機能が、x86、ppc64le、および s390x アーキテクチャーにインストールされている Compliance Operator で利用できるようになりました。must-gather ツールは、Red Hat カスタマーサポートおよびエンジニアリングに重要な設定の詳細を提供します。詳細は、Compliance Operator の must-gather ツールの使用 を参照し てください。

5.2.1.2. バグ修正

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

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. 新機能および機能拡張

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

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. 新機能および機能拡張

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

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)
  • このリリースでは、cronjob API が改良された 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 に対処します。

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

5.2.9. OpenShift Compliance Operator 1.1.0

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

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

  • ComplianceScan カスタムリソース定義 (CRD) ステータスで開始および終了のタイムスタンプが利用できるようになりました。
  • Compliance Operator は、サブスクリプション ファイルを作成することで、OperatorHub を使用してホストされたコントロールプレーンにデプロイメントできるようになりました。詳細は、Hosted Control Plane への 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

      (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.10. OpenShift Compliance Operator 1.0.0

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

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

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 で rerunner SA を所有しており、以前のバージョンからアップグレードしても 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-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.2.13.3. 非推奨

  • Install into all namespaces in the cluster を指定するか、WATCH_NAMESPACES 環境変数を "" に設定しても、すべての namespace に設定が適用されなくなりました。Compliance Operator のインストール時に指定されていない namespace にインストールされた API リソースは動作しなくなります。API リソースでは、選択した namespace またはデフォルトで openshift-compliance namespace を作成する必要がある場合があります。今回の変更により、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)
  • 以前は、デプロイメント内のセキュリティーコンテキスト制約 (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

    (BZ#2092913)

5.2.15. OpenShift Compliance Operator 0.1.52

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

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

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

    (BZ#2092913)

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) 履歴の最初のエントリーをチェックしていました。その結果、後続の 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.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、および 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.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 標準では、調整されたプロファイルのタイトルと説明が必要なため、タイトルと説明を TailoredProfile CR で設定する必要があります。
  • 以前は、調整されたプロファイルを使用する場合、特定の選択セットのみを使用して 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 にアクセス許可が追加されました。

5.2.21. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.