5.10. Compliance Operator 결과 및 수정 관리
각 ComplianceCheckResult
는 하나의 규정 준수 규칙 검사 결과를 나타냅니다. 규칙을 자동으로 수정할 수 있는 경우 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
속성에 저장됩니다.
ComplianceCheckResult 상태 | 설명 |
---|---|
PASS | 규정 준수 점검이 완료 및 통과되었습니다. |
실패 | 규정 준수 검사가 완료되었으며 실패했습니다. |
정보 | 컴플라이언스 검사가 완료되고 오류로 간주될 만큼 심각하지 않은 것을 발견했습니다. |
MANUAL | 컴플라이언스 확인에는 성공 또는 실패를 자동으로 평가할 방법이 없으며 수동으로 확인해야 합니다. |
일관되지 않음 | 컴플라이언스 점검은 다른 소스(일반적으로 클러스터 노드)의 다른 결과를 보고합니다. |
오류 | 규정 준수 검사가 실행되었지만 제대로 완료할 수 없습니다. |
적용되지 않음 | 규정 준수 점검은 적용되지 않거나 선택되지 않았기 때문에 실행되지 않았습니다. |
5.10.2. 수정 검토
수정이 포함된 ComplianceRemediation
오브젝트 및 ComplianceCheckResult
오브젝트를 모두 검토합니다. ComplianceCheckResult
오브젝트에는 검사에서 수행하는 작업과 방지를 위한 강화 작업에 관해 사람이 있을 수 있는 설명과 심각도 및 관련 보안 제어와 같은 기타 메타데이터
가 포함되어 있습니다. ComplianceRemediation
오브젝트는 ComplianceCheckResult
에서 설명하는 문제를 해결하는 방법을 나타냅니다. 첫 번째 검사 후 상태가 누락된 상태로 수정되는지 확인합니다.
다음은 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
오브젝트입니다. 플랫폼 검사의 경우 수정 페이로드는 종종 다른 종류의 오브젝트(예: ConfigMap
또는 Secret
오브젝트)에 해당하지만 일반적으로 이러한 수정을 적용하는 것은 관리자의 몫입니다. 그러지 않으면 일반 Kubernetes 오브젝트를 조작하기 위해 Compliance Operator에 매우 광범위한 권한이 있어야 하기 때문입니다. 플랫폼 검사를 수정하는 예는 본문 뒷부분에 있습니다.
수정 적용 시 수행되는 작업을 정확히 확인하기 위해 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
KubeletConfig
에 있는 machineConfigPoolSelector
가 MachineConfigPool과 일치하는 라벨과 일치하도록 MachineConfigPool
에 레이블을 추가합니다.
Compliance Operator가 수정 적용을 완료한 후 MachineConfigPool
오브젝트가 예기치 않게 일시 중지되지 않을 수 있으므로 KubeletConfig
파일에서 protectKernelDefaults: false
를 설정하지 마십시오.
프로세스
노드를 나열합니다.
$ 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
노드에 레이블을 추가합니다.
$ 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
사용자 지정
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(Machine config pool)에 추가할 레이블 이름을 정의합니다.
MCP가 성공적으로 생성되었는지 확인합니다.
$ oc get mcp -w
5.10.4. 기본 구성 값에 대한 KubeletConfig 규칙 평가
OpenShift Container Platform 인프라에는 런타임에 불완전한 구성 파일이 포함될 수 있으며 노드는 누락된 구성 옵션의 기본 구성 값을 가정합니다. 일부 설정 옵션은 명령줄 인수로 전달할 수 있습니다. 결과적으로 Compliance Operator는 규칙 검사에 사용된 옵션이 누락될 수 있으므로 노드의 구성 파일이 완료되었는지 확인할 수 없습니다.
기본 구성 값이 검사를 통과하는 잘못된 음수 결과를 방지하기 위해 Compliance Operator는 Node/Proxy API를 사용하여 노드 풀의 노드 간에 일관된 모든 구성 옵션이 해당 노드 풀 내의 모든 노드에 대한 구성을 나타내는 파일에 저장됩니다. 이렇게 하면 검사 결과의 정확성이 높아집니다.
기본 마스터
및 작업자
노드 풀 구성에서 이 기능을 사용하려면 추가 구성을 변경할 필요가 없습니다.
5.10.5. 사용자 정의 노드 풀 스캔
Compliance Operator는 각 노드 풀 구성의 사본을 유지하지 않습니다. Compliance Operator는 단일 노드 풀 내의 모든 노드에 대한 일관된 구성 옵션을 구성 파일의 사본으로 집계합니다. 그런 다음 Compliance Operator는 특정 노드 풀에 구성 파일을 사용하여 해당 풀 내의 노드에 대한 규칙을 평가합니다.
클러스터에서 기본 작업자
및 마스터
노드 풀 외부에서 사용자 정의 노드 풀을 사용하는 경우 Compliance Operator에서 해당 노드 풀에 대한 구성 파일을 집계하도록 추가 변수를 제공해야 합니다.
프로세스
마스터
,작업자
및 사용자 정의 예제 노드 풀이 포함된 예제 클러스터의 모든 풀에 대해 구성을 확인하려면ocp-var-role-master
및opc-var-role-worker
필드의 값을TailoredProfile
오브젝트의예제로
설정합니다.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
ScanSettingBinding
CR에 저장할ScanSetting
오브젝트에예제
역할을 추가합니다.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 * * *'
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-*
로 표시됩니다. 선택한 모든 노드가 이 검사를 통과한 경우에만 검사가 전달됩니다.
검증
플랫폼 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
오브젝트로 렌더링됩니다. 이후 Machine Config Operator에서 MachineConfig
오브젝트를 렌더링하고 마지막으로 각 노드에서 실행되는 머신 제어 데몬 인스턴스에서 머신 구성 풀의 모든 노드에 이 오브젝트를 적용합니다.
Machine Config Operator에서 새 MachineConfig
오브젝트를 풀의 노드에 적용하면 풀에 속하는 모든 노드가 재부팅됩니다. 이러한 방법은 복합적인 75-$scan-name-$suite-name
MachineConfig
오브젝트를 각각 다시 렌더링하는 수정을 여러 번 적용할 때 불편할 수 있습니다. 수정을 즉시 적용하지 않으려면 MachineConfigPool
오브젝트의 .spec.paused
특성을 true
로 설정하여 머신 구성 풀을 일시 중지하면 됩니다.
Compliance Operator는 수정을 자동으로 적용할 수 있습니다. ScanSetting
최상위 오브젝트에 autoApplyRemediations: true
를 설정합니다.
수정 사항 자동 적용은 신중하게 고려해야 합니다.
5.10.8. 플랫폼 점검 수동 수정
플랫폼 검사에 대한 점검은 일반적으로 다음 두 가지 이유로 관리자가 수동으로 수정해야 합니다.
- 설정해야 하는 값을 자동으로 결정할 수 없는 경우가 있습니다. 검사 중 하나를 통해 허용된 레지스트리 목록을 제공해야 하지만 스캐너에서는 조직이 허용하려는 레지스트리를 알 수 없습니다.
-
다양한 점검에서 여러 API 오브젝트를 수정하므로 클러스터의 오브젝트를 수정하려면
root
또는 슈퍼 유저 액세스 권한을 가져오기 위해 자동 수정이 필요합니다. 이 방법은 바람직하지 않습니다.
프로세스
아래 예제에서는
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
검사를 다시 실행합니다.
$ 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에서 구성을 노드로 푸시합니다.
프로세스
오래된 수정을 검색합니다.
$ 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
특성을 제거하십시오.최신 버전의 수정을 적용합니다.
$ oc -n openshift-compliance patch complianceremediations workers-scan-no-empty-passwords \ --type json -p '[{"op":"remove", "path":/spec/outdated}]'
수정 상태가
Outdated
에서Applied
로 전환됩니다.$ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords
출력 예
NAME STATE workers-scan-no-empty-passwords Applied
- 노드에 최신 수정 버전이 적용되고 노드가 재부팅됩니다.
5.10.10. 수정 적용 취소
이전에 적용한 수정을 적용 취소해야 할 수 있습니다.
프로세스
apply
플래그를false
로 설정합니다. :$ oc -n openshift-compliance \ patch complianceremediations/rhcos4-moderate-worker-sysctl-net-ipv4-conf-all-accept-redirects \ --patch '{"spec":{"apply":false}}' --type=merge
수정 상태가
NotApplied
로 변경되고 복합MachineConfig
오브젝트가 수정을 포함하지 않도록 다시 렌더링됩니다.중요수정으로 영향을 받는 모든 노드가 재부팅됩니다.
5.10.11. KubeletConfig 수정 제거
KubeletConfig
수정은 노드 수준 프로필에 포함됩니다. KubeletConfig 수정을 제거하려면 KubeletConfig
오브젝트에서 수동으로 제거해야 합니다. 이 예에서는 one-rule-tp-node-master-kubelet-eviction-thresholds-hard-imagefs-available
수정에 대한 규정 준수 검사를 제거하는 방법을 보여줍니다.
프로세스
one-rule
및 컴플라이언스 검사를 찾습니다.-tp-node-master-kubelet-eviction-thresholds-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
참고수정에서
evictionHard
kubelet 구성을 호출하는 경우evictionHard
매개변수인memory.available
,nodefs.available
,nodefs.inodesFree
,imagefs.available
,imagefs.inodesFree
를 지정해야 합니다. 모든 매개변수를 지정하지 않으면 지정된 매개변수만 적용되고 수정이 제대로 작동하지 않습니다.수정을 제거합니다.
수정 오브젝트에
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
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
수정
imagefs.available을 수동으로 제거합니다.
:KubeletConfig
오브젝트에서 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 annotation
에 나열됩니다.
가능한 경우 클러스터가 규정 준수 상태에 통합될 수 있도록 수정이 계속 생성됩니다. 그러나 이러한 통합이 항상 가능한 것은 아니며 노드 간 차이를 수동으로 수정해야 합니다. compliance.openshift.io/rescan=
옵션으로 검사에 주석을 달아 일관된 결과를 가져오도록 규정 준수 검사를 다시 실행해야 합니다.
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=