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

第5章 コンプライアンス Operator

5.1. コンプライアンス Operator リリースノート

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

これらのリリースノートは、OpenShift Container Platform での コンプライアンス Operator の開発を追跡します。

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

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

5.1.1. OpenShift Compliance Operator 1.0.0

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

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

5.1.1.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.2. OpenShift Compliance Operator 0.1.61

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

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

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

5.1.2.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.3. OpenShift コンプライアンス Operator 0.1.59

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

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

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

5.1.3.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.4. OpenShift コンプライアンス Operator 0.1.57

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

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

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

5.1.4.2. バグ修正

  • 以前のバージョンでは、コンプライアンス Operator は通知をデフォルトの openshift-compliance namespace にハードコーディングしていました。Operator がデフォルト以外の namespace にインストールされている場合、通知は予想通りに機能しませんでした。今回のリリースより、通知はデフォルト以外の openshift-compliance namespace で機能するようになりました。(BZ#2060726)
  • 以前のバージョンでは、コンプライアンス Operator は kubelet オブジェクトによって使用されるデフォルト設定を評価できず、不正確な結果と誤検出が発生していました。この新機能 は kubelet 設定を評価し、正確に報告するようになりました。(BZ#2075041)
  • 以前は、コンプライアンス 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)。
  • 以前のバージョンでは、コンプライアンス Operator は古いバージョンの operator-sdk コマンドを使用しており、非推奨の機能についてアラートが発生していました。現在、operator-sdk コマンドの更新バージョンが含まれており、廃止された機能に関するアラートが発生することはなくなりました。(BZ#2098581)
  • 以前のバージョンでは、コンプライアンス Operator は kubelet とマシン設定の関係を判別できない場合に、修復の適用に失敗しました。コンプライアンス 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)
  • 以前のバージョンでは、コンプライアンス Operator は Ignition 仕様なしでマシン設定を解析する際に API リソースを取得できず、api-check-pods プロセスがクラッシュしていました。コンプライアンス Operator は Ignition 仕様が正しくない場合も Machine Config Pool を処理するようになりました。(BZ#2117268)
  • 以前のリリースでは、modprobe 設定の値が一致しないことが原因で、修復の適用後に modprobe 設定を評価するルールが失敗することがありました。今回のリリースより、チェックおよび修復の modprobe 設定に同じ値が使用されるようになり、結果の一貫性が保たれるようになりました。(BZ#2117747)

5.1.4.3. 非推奨

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

5.1.5. OpenShift コンプライアンス Operator 0.1.53

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

5.1.5.1. バグ修正

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

5.1.5.2. 既知の問題

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

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

    (BZ#2092913)

5.1.6. OpenShift コンプライアンス Operator 0.1.52

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

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

5.1.6.2. バグ修正

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

5.1.6.3. 既知の問題

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

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

    (BZ#2092913)

5.1.7. OpenShift コンプライアンス Operator 0.1.49

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

5.1.7.1. バグ修正

  • 以前は、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.8. OpenShift コンプライアンス Operator 0.1.48

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

5.1.8.1. バグ修正

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

5.1.9. OpenShift コンプライアンス Operator 0.1.47

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

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

  • コンプライアンス 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.9.2. バグ修正

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

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

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

5.1.10. OpenShift コンプライアンス Operator 0.1.44

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

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

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

  • このリリースでは、コンプライアンス Operator は、次の North American Electric Reliability Corporation (NERC) のセキュリティープロファイルをサポートしています。

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

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

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

5.1.10.3. バグ修正

  • 以前は、スキャンの実行中に、Pod のスキャナーコンテナーの 1 つで予期しない終了が発生しました。このリリースでは、コンプライアンス 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.11. コンプライアンス Operator 0.1.39 リリースノート

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

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

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

5.1.12. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.