5.10. Compliance Operator の結果と修復の管理


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

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

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

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

$ oc get -n openshift-compliance compliancecheckresults \
  -l compliance.openshift.io/suite=workers-compliancesuite

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

$ oc get -n openshift-compliance compliancecheckresults \
-l compliance.openshift.io/scan=workers-scan

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

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

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

失敗したすべてのチェックを重大度順に一覧表示します。

$ oc get compliancecheckresults -n openshift-compliance \
-l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/check-severity=high'

出力例

NAME                                                           STATUS   SEVERITY
nist-moderate-modified-master-configure-crypto-policy          FAIL     high
nist-moderate-modified-master-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-master-enable-fips-mode                 FAIL     high
nist-moderate-modified-master-no-empty-passwords               FAIL     high
nist-moderate-modified-master-selinux-state                    FAIL     high
nist-moderate-modified-worker-configure-crypto-policy          FAIL     high
nist-moderate-modified-worker-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-worker-enable-fips-mode                 FAIL     high
nist-moderate-modified-worker-no-empty-passwords               FAIL     high
nist-moderate-modified-worker-selinux-state                    FAIL     high
ocp4-moderate-configure-network-policies-namespaces            FAIL     high
ocp4-moderate-fips-mode-enabled-on-all-nodes                   FAIL     high

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

$ oc get -n openshift-compliance 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.10.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 オブジェクトなど) 異なる種類のオブジェクトになりますが、通常は修復を適用については管理者が判断します。そうでない場合には、Compliance 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.10.3. カスタマイズされたマシン設定プールを使用するときに修復を適用する

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

重要

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

手順

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

    $ oc get nodes -n openshift-compliance

    出力例

    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 -n openshift-compliance \
    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.10.4. デフォルトの設定値をもとにした KubeletConfig ルールの評価

OpenShift Container Platform インフラストラクチャーには、実行時に不完全な設定ファイルが含まれる場合があり、ノードは、設定オプションが欠落している場合には、設定値がデフォルトであることを想定します。一部の設定オプションは、コマンドライン引数として渡すことができます。その結果、Compliance Operator はノード上の設定ファイルが完全かどうかを確認できません。これは、ルールチェックで使用されるオプションが欠落している可能性があるためです。

デフォルトの設定値がチェックに合格するといったフォールスネガティブの結果に陥らないように、Compliance Operator はノード/プロキシー API を使用してノードのプール内にあるノードごとに設定をフェッチし、次にノードプール内のノード全体で整合性が取れた設定オプションすべてをファイルに保存することで、このファイルが対象ノードプール内の全ノードの設定を表します。これにより、スキャン結果の精度が向上します。

デフォルトの マスター および ワーカー ノードプール設定でこの機能を使用するために、追加の設定変更は必要ありません。

5.10.5. カスタムノードプールのスキャン

Compliance Operator は、各ノードプール設定のコピーを維持しません。Compliance Operator は、単一ノードプール内のすべてのノードについて一貫性のある設定オプションを設定ファイルの 1 つのコピーに集約します。次に、Compliance Operator は、特定のノードプールの設定ファイルを使用して、そのプール内のノードに対してルールを評価します。

クラスターがデフォルトの ワーカー ノードおよび マスター ノードプール外のカスタムノードプールを使用する場合、Compliance Operator がそのノードプールの設定ファイルを集約できるように追加の変数を指定する必要があります。

手順

  1. masterworker、およびカスタムのexample ノードプールを含むサンプルクラスター内のすべてのプールに対して設定をチェックするには、TailoredProfile オブジェクトの ocp-var-role-master および opc-var-role-worker フィールドの値を example に設定します。

    apiVersion: compliance.openshift.io/v1alpha1
    kind: TailoredProfile
    metadata:
      name: cis-example-tp
    spec:
      extends: ocp4-cis
      title: My modified NIST profile to scan example nodes
      setValues:
      - name: ocp4-var-role-master
        value: example
        rationale: test for example nodes
      - name: ocp4-var-role-worker
        value: example
        rationale: test for example nodes
      description: cis-example-scan
  2. ScanSettingBinding CR に保存される ScanSetting オブジェクトに example ロールを追加します。

    apiVersion: compliance.openshift.io/v1alpha1
    kind: ScanSetting
    metadata:
      name: default
      namespace: openshift-compliance
    rawResultStorage:
      rotation: 3
      size: 1Gi
    roles:
    - worker
    - master
    - example
    scanTolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/master
      operator: Exists
    schedule: '0 1 * * *'
  3. ScanSettingBinding CR を使用するスキャンを作成します。

    apiVersion: compliance.openshift.io/v1alpha1
    kind: ScanSettingBinding
    metadata:
      name: cis
      namespace: openshift-compliance
    profiles:
    - apiGroup: compliance.openshift.io/v1alpha1
      kind: Profile
      name: ocp4-cis
    - apiGroup: compliance.openshift.io/v1alpha1
      kind: Profile
      name: ocp4-cis-node
    - apiGroup: compliance.openshift.io/v1alpha1
      kind: TailoredProfile
      name: cis-example-tp
    settingsRef:
      apiGroup: compliance.openshift.io/v1alpha1
      kind: ScanSetting
      name: default

Compliance Operator は Node/Proxy API オブジェクトを使用してランタイム KubeletConfig をチェックし、ocp-var-role-master および ocp-var-role-worker などの変数を使用してチェックを実行するノードを判別します。ComplianceCheckResult では、KubeletConfig ルールは ocp4-cis-kubelet-* と表示されます。スキャンは、選択したすべてのノードがこのチェックに合格した場合にのみ、合格します。

検証

  • Platform KubeletConfig ルールは、Node/Proxy オブジェクトを介してチェックされます。これらのルールは、以下のコマンドを実行して検索できます。

    $ oc get rules -o json | jq '.items[] | select(.checkType == "Platform") | select(.metadata.name | contains("ocp4-kubelet-")) | .metadata.name'

5.10.6. KubeletConfig サブプールの修復

KubeletConfig 修復ラベルは MachineConfigPool サブプールに適用できます。

手順

  • ラベルをサブプール MachineConfigPool CR に追加します。

    $ oc label mcp <sub-pool-name> pools.operator.machineconfiguration.openshift.io/<sub-pool-name>=

5.10.7. 修復の適用

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

$ oc -n openshift-compliance \
patch complianceremediations/<scan-name>-sysctl-net-ipv4-conf-all-accept-redirects \
--patch '{"spec":{"apply":true}}' --type=merge

Compliance 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 に設定してマシン設定プールを一時停止できます。

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

警告

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

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

通常、プラットフォームスキャンをチェックする場合、以下の 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 -n openshift-compliance \
    annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

5.10.9. 修復の更新

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

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

手順

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

    $ oc -n openshift-compliance get complianceremediations \
    -l complianceoperator.openshift.io/outdated-remediation=

    出力例

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

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

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

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

    $ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords

    出力例

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

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

5.10.10. 修復の適用解除

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

手順

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

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

    重要

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

5.10.11. 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 -n openshift-compliance 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 -n openshift-compliance 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 -n openshift-compliance 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 -n openshift-compliance KubeletConfig compliance-operator-kubelet-master
      重要

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

注記

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

5.10.12. 一貫性のない ComplianceScan

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

重要

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

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

プール内のマシン数は非常に大きくなる可能性があるため、Compliance 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 -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

5.10.13. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.