1.7. Compliance Operator 수정 관리

ComplianceCheckResult는 하나의 규정 준수 규칙 검사 결과를 나타냅니다. 규칙을 자동으로 수정할 수 있는 경우 ComplianceCheckResult가 소유한 동일한 이름의 ComplianceRemediation 오브젝트가 생성됩니다. 요청하지 않는 경우 수정은 자동으로 적용되지 않으므로 OpenShift Container Platform 관리자는 수정을 통해 수행되는 작업을 검토하고 확인한 후에만 수정을 적용할 수 있습니다.

1.7.1. 수정 검토

수정이 포함된 ComplianceRemediation 오브젝트 및 ComplianceCheckResult 오브젝트를 모두 검토합니다. ComplianceCheckResult 오브젝트에는 검사에서 수행하는 작업과 방지를 위한 강화 작업에 관해 사람이 있을 수 있는 설명과 심각도 및 관련 보안 제어와 같은 기타 메타데이터가 포함되어 있습니다. ComplianceRemediation 오브젝트는 ComplianceCheckResult에서 설명하는 문제를 해결하는 방법을 나타냅니다.

다음은 sysctl-net-ipv4-conf-all-accept-redirects라는 검사와 수정의 예입니다. 이 예는 specstatus만 표시하고 metadata는 생략하도록 수정되었습니다.

spec:
  apply: false
  current:
  object:
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    spec:
      config:
        ignition:
          version: 2.2.0
        storage:
          files:
            - contents:
              source: data:,net.ipv4.conf.all.accept_redirects%3D0
              filesystem: root
              mode: 420
              path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
  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

1.7.2. 수정 적용

부울 특성 spec.apply는 Compliance Operator에서 수정을 적용해야 하는지를 제어합니다. 특성을 true로 설정하면 수정을 적용할 수 있습니다.

$ oc 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를 설정합니다.

주의

수정 사항 자동 적용은 신중하게 고려해야 합니다.

1.7.3. 플랫폼 점검 수동 수정

플랫폼 검사에 대한 점검은 일반적으로 다음 두 가지 이유로 관리자가 수동으로 수정해야 합니다.

  • 설정해야 하는 값을 자동으로 결정할 수 없는 경우가 있습니다. 검사 중 하나를 통해 허용된 레지스트리 목록을 제공해야 하지만 스캐너에서는 조직이 허용하려는 레지스트리를 알 수 없습니다.
  • 다양한 점검에서 여러 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=

1.7.4. 수정 업데이트

새 버전의 규정 준수 콘텐츠를 사용하는 경우 이전 버전과 다른 새 버전의 수정을 제공할 수 있습니다. Compliance Operator는 이전 버전의 수정을 적용한 상태로 유지됩니다. OpenShift Container Platform 관리자에게는 검토하고 적용할 새 버전에 대한 알림이 제공됩니다. 이전에 적용되었지만 업데이트된 ComplianceRemediation 오브젝트는 상태가 Outdated로 변경됩니다. 오래된 오브젝트는 쉽게 검색할 수 있도록 레이블이 지정됩니다.

이전에 적용된 수정 내용은 ComplianceRemediation 오브젝트의 spec.outdated 특성에 저장되고 새로 업데이트된 내용은 spec.current 특성에 저장됩니다. 콘텐츠가 최신 버전으로 업데이트되면 관리자는 수정을 검토해야 합니다. spec.outdated 특성이 존재하는 동안에는 결과 MachineConfig 오브젝트를 렌더링하는 데 사용됩니다. spec.outdated 특성이 제거되면 Compliance Operator에서 결과 MachineConfig 오브젝트를 다시 렌더링하고 이로 인해 Operator에서 구성을 노드로 푸시합니다.

프로세스

  1. 오래된 수정을 검색합니다.

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

    출력 예

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

    현재 적용된 수정은 Outdated 특성에 저장되고 적용되지 않은 새 수정은 Current 특성에 저장됩니다. 새 버전에 만족한다면 Outdated 필드를 제거하십시오. 업데이트된 콘텐츠를 유지하려면 CurrentOutdated 특성을 제거하십시오.

  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. 노드에 최신 수정 버전이 적용되고 노드가 재부팅됩니다.

1.7.5. 수정 적용 취소

이전에 적용한 수정을 적용 취소해야 할 수 있습니다.

프로세스

  1. 플래그를 false로 전환합니다.

    $ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects
  2. 수정 상태가 NotApplied로 변경되고 복합 MachineConfig 오브젝트가 수정을 포함하지 않도록 다시 렌더링됩니다.

    중요

    수정으로 영향을 받는 모든 노드가 재부팅됩니다.

1.7.6. 일관성 없는 수정

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 annotate compliancescans/<scan_name> compliance.openshift.io/rescan=

1.7.7. 실패한 규정 준수 검사 결과에 대한 필터

기본적으로 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 라벨이 지정된 경우 ComplianceCheckResult 오브젝트에 관련 수정이 있습니다. 수정 이름은 검사 이름과 동일합니다.

자동으로 수정할 수 있는 모든 실패 검사를 나열합니다.

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

수동으로 수정해야 하는 모든 실패 검사를 나열합니다.

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

수동 수정 단계는 일반적으로 ComplianceCheckResult 오브젝트의 description 특성에 저장됩니다.