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

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

download PDF

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

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

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

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

5.1.1. OpenShift Compliance Operator 0.1.53

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

5.1.1.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.1.2. 既知の問題

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

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

    (BZ#2092913)

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

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

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

  • FedRAMP の SCAP プロファイル high が、OpenShift Container Platform 環境で使用できるようになりました。詳細は、Supported compliance profiles を参照してください。

5.1.2.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.2.3. 既知の問題

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

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

    (BZ#2092913)

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

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

5.1.3.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 のリストが切り捨てられたため、ルールが失敗しました。これで、namespaces リスト全体がリクエストされ、設定されたネットワークポリシーをチェックするためのルールは、500 を超える namespaces を持つデプロイメントで機能します。(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.4. OpenShift コンプライアンス Operator 0.1.48

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

5.1.4.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.5. OpenShift コンプライアンス Operator 0.1.47

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

5.1.5.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.5.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.6. OpenShift コンプライアンス Operator 0.1.44

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

5.1.6.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.6.2. テンプレートと変数の使用

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

5.1.6.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.7. コンプライアンス Operator 0.1.39 リリースノート

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

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

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

5.1.8. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.