検索

5.9. コンプライアンス Operator の結果と修復の管理

download PDF

それぞれの ComplianceCheckResult は、1 つのコンプライアンスルールチェックの結果を表します。ルールを自動的に修復できる場合、ComplianceCheckResult によって所有される、同じ名前を持つ ComplianceRemediation オブジェクトが作成されます。修復が要求されない限り、修復は自動的に適用されません。これにより、OpenShift Container Platform の管理者は修復内容を確認し、検証後にのみ修復を適用することができます。

5.9.1. コンプライアンスチェック結果のフィルター

デフォルトで、ComplianceCheckResult オブジェクトには、チェックのクエリーおよび結果の生成後に次のステップを決定することを可能にする便利なラベルが複数付けられます。

特定のスイートに属するチェックを一覧表示します。

$ oc get compliancecheckresults -l compliance.openshift.io/suite=example-compliancesuite

特定のスキャンに属するチェックを一覧表示します。

$ oc get compliancecheckresults -l compliance.openshift.io/scan=example-compliancescan

すべての ComplianceCheckResult オブジェクトが ComplianceRemediation オブジェクトを作成する訳ではありません。自動的に修復できる ComplianceCheckResult オブジェクトのみになります。ComplianceCheckResult オブジェクトには、compliance.openshift.io/automated-remediation ラベルでラベル付けされる場合に関連する修復が含まれます。修復の名前はチェックの名前と同じです。

自動的に修復できる障害のあるチェックをすべて一覧表示します。

$ oc get compliancecheckresults -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'

手動で修復する必要のある障害のあるチェックをすべて一覧表示します。

$ oc get compliancecheckresults -l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'

手動による修復の手順は、通常 ComplianceCheckResult オブジェクトの description 属性に保存されます。

表5.3 ComplianceCheckResult Status
ComplianceCheckResult Status説明

PASS

コンプライアンスチェックが完了し、パスしました。

FAIL

コンプライアンスチェックが完了するまで実行され、失敗しました。

INFO

コンプライアンスチェックが完了するまで実行され、エラーと見なされるほど深刻ではないものが見つかりました。

MANUAL

コンプライアンスチェックには、成功または失敗を自動的に評価する方法がないため、手動でチェックする必要があります。

INCONSISTENT

コンプライアンスチェックは、さまざまなソース (通常はクラスターノード) からのさまざまな結果を報告します。

ERROR

コンプライアンスチェックは実行されましたが、正しく完了できませんでした。

NOT-APPLICABLE

該当しない、または選択されていないため、コンプライアンスチェックは実行されませんでした。

5.9.2. 修復の確認

ComplianceRemediation オブジェクト、および修復を所有する ComplianceCheckResult オブジェクトの両方を確認します。ComplianceCheckResult オブジェクトには、チェック内容やサーバーの強化措置などの人間が判読できる記述、および重大度や関連するセキュリティーコントロールなどの他の metadata が含まれます。ComplianceRemediation オブジェクトは、ComplianceCheckResult に説明されている問題を修正する方法を表します。最初のスキャン後、MissingDependencies 状態の修復を確認します。

以下は、sysctl-net-ipv4-conf-all-accept-redirects というチェックおよび修復の例です。この例では、spec および status のみを表示し、metadata は省略するように編集されています。

spec:
  apply: false
  current:
  object:
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
              mode: 0644
              contents:
                source: data:,net.ipv4.conf.all.accept_redirects%3D0
  outdated: {}
status:
  applicationState: NotApplied

修復ペイロードは spec.current 属性に保存されます。ペイロードには Kubernetes オブジェクトを使用することができますが、この修復はノードスキャンによって生成されたため、上記の例の修復ペイロードは MachineConfig オブジェクトになります。Platform スキャンでは、修復ペイロードは多くの場合 (ConfigMapSecret オブジェクトなど) 異なる種類のオブジェクトになりますが、通常は修復を適用については管理者が判断します。そうでない場合には、コンプライアンス Operator には汎用の Kubernetes オブジェクトを操作するために非常に幅広いパーミッションのセットが必要になるためです。Platform チェックの修復例は、後ほど提供されます。

修復が適用される際に修復内容を正確に確認できるようにするために、MachineConfig オブジェクトの内容は設定の Ignition オブジェクトを使用します。形式についての詳細は、Ignition 仕様 を参照してください。この例では、spec.config.storage.files[0].path 属性は、この修復によって作成されるファイル (/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf) を指定し、spec.config.storage.files[0].contents.source 属性はそのファイルの内容を指定します。

注記

ファイルの内容は URL でエンコードされます。

以下の Python スクリプトを使用して、コンテンツを表示します。

$ echo "net.ipv4.conf.all.accept_redirects%3D0" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"

出力例

net.ipv4.conf.all.accept_redirects=0

5.9.3. カスタマイズされたマシン設定プールを使用するときに修復を適用する

カスタム MachineConfigPool を作成するときは、MachineConfigPool にラベルを追加して、KubeletConfig に存在する machineConfigPoolSelector がそのラベルを MachineConfigPool と一致させることができるようにします。

重要

コンプライアンス Operator が修復の適用を終了した後に、MachineConfigPool オブジェクトが予期せず一時停止を解除できない可能性があるため、KubeletConfig ファイルでは、protectKernelDefaults:false を設定しないでください。

手順

  1. ノードを一覧表示します。

    $ oc get nodes

    出力例

    NAME                                       STATUS  ROLES  AGE    VERSION
    ip-10-0-128-92.us-east-2.compute.internal  Ready   master 5h21m  v1.23.3+d99c04f
    ip-10-0-158-32.us-east-2.compute.internal  Ready   worker 5h17m  v1.23.3+d99c04f
    ip-10-0-166-81.us-east-2.compute.internal  Ready   worker 5h17m  v1.23.3+d99c04f
    ip-10-0-171-170.us-east-2.compute.internal Ready   master 5h21m  v1.23.3+d99c04f
    ip-10-0-197-35.us-east-2.compute.internal  Ready   master 5h22m  v1.23.3+d99c04f

  2. ノードにラベルを追加します。

    $ oc label node ip-10-0-166-81.us-east-2.compute.internal node-role.kubernetes.io/<machine_config_pool_name>=

    出力例

    node/ip-10-0-166-81.us-east-2.compute.internal labeled

  3. カスタム MachineConfigPool CR を作成します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: <machine_config_pool_name>
      labels:
        pools.operator.machineconfiguration.openshift.io/<machine_config_pool_name>: '' 1
    spec:
      machineConfigSelector:
      matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,<machine_config_pool_name>]}
      nodeSelector:
      matchLabels:
        node-role.kubernetes.io/<machine_config_pool_name>: ""
    1
    labels フィールドは、マシン設定プール (MCP) に追加するラベル名を定義します。
  4. MCP が正常に作成されたことを確認します。

    $ oc get mcp -w

5.9.4. 修復の適用

ブール値の属性 spec.apply は、コンプライアンス Operator で修復を適用するかどうかを制御します。属性を true に設定すると、修復を適用することができます。

$ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects --patch '{"spec":{"apply":true}}' --type=merge

コンプライアンス Operator が適用された修復を処理した後に、status.ApplicationState 属性は Applied に、または正しくない場合には Error に切り替わります。マシン設定の修復が適用されると、その修復と他のすべての適用済みの修復が 75-$scan-name-$suite-name という名前の MachineConfig オブジェクトにレンダリングされます。MachineConfig オブジェクトはその後 Machine Config Operator によってレンダリングされ、最終的に各ノードで実行されるマシン制御デーモンのインスタンスによってマシン設定プールのすべてのノードに適用されます。

Machine Config Operator が新規 MachineConfig オブジェクトをプール内のノードに適用すると、そのプールに属するすべてのノードが再起動されることに注意してください。これは、それぞれが複合の 75-$scan-name-$suite-name MachineConfig オブジェクトを再度レンダリングする、複数の修復を適用する際に不都合が生じる可能性があります。修復をすぐに適用しないようにするには、MachineConfigPool オブジェクトの .spec.paused 属性を true に設定してマシン設定プールを一時停止できます。

コンプライアンス Operator は修復を自動的に適用できます。ScanSetting の最上位のオブジェクトに autoApplyRemediations: true を設定します。

警告

修復の自動敵に適用するかどうかについては、慎重に考慮する必要があります。

5.9.5. プラットフォームチェックの手動による修復

通常、プラットフォームスキャンをチェックする場合、以下の 2 つの理由のために管理者が手動で修復する必要があります。

  • 設定する必要のある値は、常に自動的に判別できる訳ではありません。チェックのいずれかで許可されたレジストリーの一覧が指定されることが必要になりますが、スキャナー側が組織が許可する必要のあるレジストリーを認識する方法はありません。
  • 異なるチェックで異なる API オブジェクトが変更されるため、クラスター内のオブジェクトを変更するために自動化された修復で root またはスーパーユーザーアクセスを所有することが要求されますが、これは推奨されていません。

手順

  1. 以下の例では、ocp4-ocp-allowed-registries-for-import ルールを使用します。これはデフォルトの OpenShift Container Platform のインストール時に失敗します。ルール oc get rule.compliance/ocp4-ocp-allowed-registries-for-import -oyaml を検査します。このルールは、allowedRegistriesForImport 属性を設定して、ユーザーのイメージのインポートを許可するレジストリーを制限します。さらに、ルールの warning 属性はチェックされた API オブジェクトを表示するため、これを変更し、問題を修復できます。

    $ oc edit image.config.openshift.io/cluster

    出力例

    apiVersion: config.openshift.io/v1
    kind: Image
    metadata:
      annotations:
        release.openshift.io/create-only: "true"
      creationTimestamp: "2020-09-10T10:12:54Z"
      generation: 2
      name: cluster
      resourceVersion: "363096"
      selfLink: /apis/config.openshift.io/v1/images/cluster
      uid: 2dcb614e-2f8a-4a23-ba9a-8e33cd0ff77e
    spec:
      allowedRegistriesForImport:
      - domainName: registry.redhat.io
    status:
      externalRegistryHostnames:
      - default-route-openshift-image-registry.apps.user-cluster-09-10-12-07.devcluster.openshift.com
      internalRegistryHostname: image-registry.openshift-image-registry.svc:5000

  2. スキャンを再実行します。

    $ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=

5.9.6. 修復の更新

新しいバージョンのコンプライアンスコンテンツが使用されると、以前のバージョンとは異なる新しいバージョンの修復が提供される可能性があります。コンプライアンス Operator は、適用される修復の以前のバージョンを保持します。OpenShift Container Platform の管理者は、確認し、適用する新規バージョンについても通知されます。以前に適用されたものの、更新された ComplianceRemediation オブジェクトはそのステータスを Outdated に変更します。古いオブジェクトには簡単に検索できるようにラベルが付けられます。

以前に適用された修復内容は ComplianceRemediation オブジェクトの spec.outdated 属性に保存され、新規に更新された内容は spec.current 属性に保存されます。コンテンツを新しいバージョンに更新した後に、管理者は修復を確認する必要があります。spec.outdated 属性が存在する限り、これは結果として作成される MachineConfig オブジェクトをレンダリングするために使用されます。spec.outdated 属性が削除された後に、コンプライアンス Operator は結果として生成される MachineConfig オブジェクトを再度レンダリングし、これにより Operator は設定をノードにプッシュします。

手順

  1. 古い修復について検索します。

    $ oc get complianceremediations -lcomplianceoperator.openshift.io/outdated-remediation=

    出力例

    NAME                              STATE
    workers-scan-no-empty-passwords   Outdated

    現在適用されている修復は Outdated 属性に保存され、新規の、適用されていない修復は Current 属性に保存されます。新規バージョンに問題がなれば、Outdated フィールドを削除します。更新された内容を保持する必要がある場合には、 Current および Outdated 属性を削除します。

  2. 修復の新しいバージョンを適用します。

    $ oc patch complianceremediations workers-scan-no-empty-passwords --type json -p '[{"op":"remove", "path":/spec/outdated}]'
  3. 修復の状態は、Outdated から Applied に切り替わります。

    $ oc get complianceremediations workers-scan-no-empty-passwords

    出力例

    NAME                              STATE
    workers-scan-no-empty-passwords   Applied

  4. ノードは新規の修復バージョンを適用し、再起動します。

5.9.7. 修復の適用解除

以前に適用された修復を適用解除することが必要になる場合があります。

手順

  1. apply フラグを false に設定します。

    $ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects -p '{"spec":{"apply":false}}' --type=merge
  2. 修復ステータスは NotApplied に変更され、複合の MachineConfig オブジェクトは修復を含まないように再度レンダリングされます。

    重要

    修復を含む影響を受けるすべてのノードが再起動されます。

5.9.8. KubeletConfig 修復の削除

KubeletConfig の修正は、ノードレベルのプロファイルに含まれています。KubeletConfig 修復を削除するには、KubeletConfig オブジェクトから手動で削除する必要があります。この例は、one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available 修正のコンプライアンスチェックを削除する方法を示しています。

手順

  1. one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available 修復の scan-name およびコンプライアンスチェックを見つけます。

    $ oc get remediation one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -o yaml

    出力例

    apiVersion: compliance.openshift.io/v1alpha1
    kind: ComplianceRemediation
    metadata:
      annotations:
        compliance.openshift.io/xccdf-value-used: var-kubelet-evictionhard-imagefs-available
      creationTimestamp: "2022-01-05T19:52:27Z"
      generation: 1
      labels:
        compliance.openshift.io/scan-name: one-rule-tp-node-master 1
        compliance.openshift.io/suite: one-rule-ssb-node
      name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
      namespace: openshift-compliance
      ownerReferences:
      - apiVersion: compliance.openshift.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ComplianceCheckResult
        name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
        uid: fe8e1577-9060-4c59-95b2-3e2c51709adc
      resourceVersion: "84820"
      uid: 5339d21a-24d7-40cb-84d2-7a2ebb015355
    spec:
      apply: true
      current:
        object:
          apiVersion: machineconfiguration.openshift.io/v1
          kind: KubeletConfig
          spec:
            kubeletConfig:
              evictionHard:
                imagefs.available: 10% 2
      outdated: {}
      type: Configuration
    status:
      applicationState: Applied

    1
    修復のスキャン名。
    2
    KubeletConfig オブジェクトに追加された修復。
    注記

    修復によって evictionHard kubelet 設定が呼び出される場合は、すべての evictionHard パラメーター (memory.availablenodefs.availablenodefs.inodesFreeimagefs.available、および imagefs.inodesFree) を指定する必要があります。すべてのパラメーターを指定しないと、指定したパラメーターのみが適用され、修正が正しく機能しません。

  2. 修復を削除します。

    1. 修復オブジェクトの apply を false に設定します。

      $ oc patch complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -p '{"spec":{"apply":false}}' --type=merge
    2. scan-name を使用して、修復が適用された KubeletConfig オブジェクトを見つけます。

      $ oc get kubeletconfig --selector compliance.openshift.io/scan-name=one-rule-tp-node-master

      出力例

      NAME                                 AGE
      compliance-operator-kubelet-master   2m34s

    3. KubeletConfig オブジェクトから修復 imagefs.available: 10% を手動で削除します。

      $ oc edit KubeletConfig compliance-operator-kubelet-master
      重要

      修復を含む影響を受けるすべてのノードが再起動されます。

注記

また、修正を自動適用する調整済みプロファイルのスケジュールされたスキャンからルールを除外する必要があります。除外しない場合、修正は次のスケジュールされたスキャン中に再適用されます。

5.9.9. 一貫性のない ComplianceScan

ScanSetting オブジェクトは、ScanSetting または ScanSettingBinding オブジェクトから生成されるコンプライアンススキャンがスキャンするノードロールを一覧表示します。通常、各ノードのロールはマシン設定プールにマップされます。

重要

マシン設定プールのすべてのマシンが同一であり、プールのノードからのすべてのスキャン結果が同一であることが予想されます。

一部の結果が他とは異なる場合、コンプライアンス Operator は一部のノードが INCONSISTENT として報告される ComplianceCheckResult オブジェクトにフラグを付けます。すべての ComplianceCheckResult オブジェクトには、compliance.openshift.io/inconsistent-check のラベルも付けられます。

プール内のマシン数は非常に大きくなる可能性があるため、コンプライアンス Operator は最も一般的な状態を検索し、一般的な状態とは異なるノードを一覧表示しようとします。最も一般的な状態は compliance.openshift.io/most-common-status アノテーションに保存され、アノテーション compliance.openshift.io/inconsistent-source には、最も一般的なステータスとは異なるチェックステータスの hostname:status のペアが含まれます。共通状態が見つからない場合、すべての hostname:status ペアが compliance.openshift.io/inconsistent-source アノテーションに一覧表示されます。

可能な場合は、修復が依然として作成され、クラスターが準拠したステータスに収束できるようにします。ただし、これが常に実行可能な訳ではなく、ノード間の差異の修正は手作業で行う必要があります。スキャンに compliance.openshift.io/rescan= オプションのアノテーションを付けて一貫性のある結果を取得するために、コンプライアンススキャンを再実行する必要があります。

$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=

5.9.10. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.