5.6. Compliance Operator 검사 관리

프로세스

1. 다음 명령을 실행하여 ScanSetting 오브젝트를 검사합니다.

   $ oc describe scansettings default -n openshift-compliance

   출력 예

   Name:                  default
   Namespace:             openshift-compliance
   Labels:                <none>
   Annotations:           <none>
   API Version:           compliance.openshift.io/v1alpha1
   Kind:                  ScanSetting
   Max Retry On Timeout:  3
   Metadata:
     Creation Timestamp:  2024-07-16T14:56:42Z
     Generation:          2
     Resource Version:    91655682
     UID:                 50358cf1-57a8-4f69-ac50-5c7a5938e402
   Raw Result Storage:
     Node Selector:
       node-role.kubernetes.io/master:
     Pv Access Modes:
       ReadWriteOnce 1
     Rotation:            3 2
     Size:                1Gi 3
     Storage Class Name:  standard 4
     Tolerations:
       Effect:              NoSchedule
       Key:                 node-role.kubernetes.io/master
       Operator:            Exists
       Effect:              NoExecute
       Key:                 node.kubernetes.io/not-ready
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoExecute
       Key:                 node.kubernetes.io/unreachable
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoSchedule
       Key:                 node.kubernetes.io/memory-pressure
       Operator:            Exists
   Roles:
     master 5
     worker 6
   Scan Tolerations: 7
     Operator:           Exists
   Schedule:             0 1 * * * 8
   Show Not Applicable:  false
   Strict Node Scan:     true
   Suspend:              false
   Timeout:              30m
   Events:               <none>

   1

   Compliance Operator는 검사 결과가 포함된 PV(영구 볼륨)를 생성합니다. 기본적으로 PV는 Compliance Operator에서 클러스터에 구성된 스토리지 클래스에 대한 가정을 할 수 없기 때문에 액세스 모드 ReadWriteOnce를 사용합니다. 대부분의 클러스터에서 ReadWriteOnce 액세스 모드를 사용할 수 있습니다. 검사 결과를 가져오려면 볼륨을 바인딩하는 도우미 Pod를 사용하여 이를 수행할 수 있습니다. ReadWriteOnce 액세스 모드를 사용하는 볼륨은 한 번에 하나의 Pod에서만 마운트할 수 있으므로 도우미 Pod를 삭제해야 합니다. 그러지 않으면 Compliance Operator가 후속 검사에 볼륨을 재사용할 수 없습니다.

   2

   Compliance Operator는 세 번의 후속 검사 결과를 볼륨에 보관합니다. 이전 검사는 순환됩니다.

   3

   Compliance Operator는 검사 결과에 대해 1GB의 스토리지를 할당합니다.

   4

   scansetting.rawResultStorage.storageClassName 필드는 원시 결과를 저장하기 위해 PersistentVolumeClaim 오브젝트를 생성할 때 사용할 storageClassName 값을 지정합니다. 기본값은 null이며 클러스터에 구성된 기본 스토리지 클래스를 사용하려고 합니다. 기본 클래스가 지정되지 않은 경우 기본 클래스를 설정해야 합니다.

   5 6

   검사 설정에서 클러스터 노드를 검사하는 프로필을 사용하는 경우 이러한 노드 역할을 검사합니다.

   7

   기본 검사 설정 오브젝트는 모든 노드를 검사합니다.

   8

   기본 검사 설정 오브젝트는 매일 01:00에 검사를 실행합니다.

   기본 검사 설정 대신 다음과 같은 설정이 있는 default-auto-apply를 사용할 수 있습니다.

   Name:                      default-auto-apply
   Namespace:                 openshift-compliance
   Labels:                    <none>
   Annotations:               <none>
   API Version:               compliance.openshift.io/v1alpha1
   Auto Apply Remediations:   true 1
   Auto Update Remediations:  true 2
   Kind:                      ScanSetting
   Metadata:
     Creation Timestamp:  2022-10-18T20:21:00Z
     Generation:          1
     Managed Fields:
       API Version:  compliance.openshift.io/v1alpha1
       Fields Type:  FieldsV1
       fieldsV1:
         f:autoApplyRemediations:
         f:autoUpdateRemediations:
         f:rawResultStorage:
           .:
           f:nodeSelector:
             .:
             f:node-role.kubernetes.io/master:
           f:pvAccessModes:
           f:rotation:
           f:size:
           f:tolerations:
         f:roles:
         f:scanTolerations:
         f:schedule:
         f:showNotApplicable:
         f:strictNodeScan:
       Manager:         compliance-operator
       Operation:       Update
       Time:            2022-10-18T20:21:00Z
     Resource Version:  38840
     UID:               8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
   Raw Result Storage:
     Node Selector:
       node-role.kubernetes.io/master:
     Pv Access Modes:
       ReadWriteOnce
     Rotation:  3
     Size:      1Gi
     Tolerations:
       Effect:              NoSchedule
       Key:                 node-role.kubernetes.io/master
       Operator:            Exists
       Effect:              NoExecute
       Key:                 node.kubernetes.io/not-ready
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoExecute
       Key:                 node.kubernetes.io/unreachable
       Operator:            Exists
       Toleration Seconds:  300
       Effect:              NoSchedule
       Key:                 node.kubernetes.io/memory-pressure
       Operator:            Exists
   Roles:
     master
     worker
   Scan Tolerations:
     Operator:           Exists
   Schedule:             0 1 * * *
   Show Not Applicable:  false
   Strict Node Scan:     true
   Events:               <none>

   1 2

   autoUpdateRemediations 및 autoApplyRemediations 플래그를 true로 설정하면 추가 단계 없이 자동으로 조정되는 ScanSetting 오브젝트를 쉽게 생성할 수 있습니다.

2. 기본 ScanSetting 오브젝트에 바인딩하는 ScanSettingBinding 오브젝트를 생성하고 cis 및 cis-node 프로파일을 사용하여 클러스터를 검사합니다. 예를 들면 다음과 같습니다.

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

3. 다음을 실행하여 ScanSettingBinding 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml -n openshift-compliance

   프로세스의 이 시점에서 ScanSettingBinding 오브젝트는 Binding 및 Bound 설정을 기반으로 조정됩니다. Compliance Operator는 ComplianceSuite 오브젝트 및 관련 ComplianceScan 오브젝트를 생성합니다.

4. 다음을 실행하여 컴플라이언스 검사 진행 상황을 따르십시오.

   $ oc get compliancescan -w -n openshift-compliance

   검사는 스캔 단계를 통해 진행되며 완료되면 DONE 단계에 도달합니다. 대부분의 경우 검사 결과는 NON-COMPLIANT입니다. 검사 결과를 검토하고 업데이트 적용 작업을 시작하여 클러스터를 준수하도록 할 수 있습니다. 자세한 내용은 Compliance Operator 수정 관리를 참조하십시오.

프로세스

1. 다음 명령을 실행하여 검사할 호스팅 클러스터의 이름과 네임스페이스 를 가져옵니다.

   $ oc get hostedcluster -A

   출력 예

   NAMESPACE       NAME                   VERSION   KUBECONFIG                              PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
   local-cluster   79136a1bdb84b3c13217   4.13.5    79136a1bdb84b3c13217-admin-kubeconfig   Completed   True        False         The hosted control plane is available

2. 관리 클러스터에서 검사 프로필을 확장한 TailoredProfile 을 생성하고 스캔할 Hosted Cluster의 이름과 네임스페이스를 정의합니다.

   management-tailoredprofile.yaml의 예

   apiVersion: compliance.openshift.io/v1alpha1
   kind: TailoredProfile
   metadata:
     name: hypershift-cisk57aw88gry
     namespace: openshift-compliance
   spec:
     description: This profile test required rules
     extends: ocp4-cis 1
     title: Management namespace profile
     setValues:
     - name: ocp4-hypershift-cluster
       rationale: This value is used for HyperShift version detection
       value: 79136a1bdb84b3c13217 2
     - name: ocp4-hypershift-namespace-prefix
       rationale: This value is used for HyperShift control plane namespace detection
       value: local-cluster 3

   1

   변수. 호스트된 컨트롤 플레인 관리 클러스터에서 ocp4-cis 및 ocp4-pci-dss 프로필만 지원됩니다.

   2

   값은 이전 단계의 출력에서 NAME 입니다.

   3

   값은 이전 단계의 출력에서 NAMESPACE 입니다.

3. TailoredProfile을 생성합니다.

   $ oc create -n openshift-compliance -f mgmt-tp.yaml

프로세스

1. RHCOS(Red Hat Enterprise Linux CoreOS) ProfileBundle에 사용 가능한 규칙을 찾습니다.

   $ oc get rules.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4

2. 해당 ProfileBundle에서 사용 가능한 변수를 찾습니다.

   $ oc get variables.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4

3. nist-moderate-modified 라는 맞춤형 프로필을 만듭니다.

   1. nist-moderate-modified 맞춤형 프로필에 추가할 규칙을 선택합니다. 이 예제에서는 두 개의 규칙을 비활성화하고 하나의 값을 변경하여 rhcos4-moderate 프로필을 확장합니다. rationale 값을 사용하여 이러한 변경이 이루어진 이유를 설명합니다.

      예: new-profile-node.yaml

      apiVersion: compliance.openshift.io/v1alpha1
      kind: TailoredProfile
      metadata:
        name: nist-moderate-modified
      spec:
        extends: rhcos4-moderate
        description: NIST moderate profile
        title: My modified NIST moderate profile
        disableRules:
        - name: rhcos4-file-permissions-var-log-messages
          rationale: The file contains logs of error messages in the system
        - name: rhcos4-account-disable-post-pw-expiration
          rationale: No need to check this as it comes from the IdP
        setValues:
        - name: rhcos4-var-selinux-state
          rationale: Organizational requirements
          value: permissive

      표 5.9. spec 변수의 속성

      속성	설명
      extends	이 TailoredProfile이 빌드되는 Profile 오브젝트의 이름입니다.
      title	TailoredProfile의 사람이 읽을 수 있는 제목입니다.
      disableRules	이름 및 이유 쌍 목록입니다. 각 이름은 비활성화할 규칙 오브젝트의 이름을 나타냅니다. 이유 값은 규칙이 비활성화된 이유를 설명하는 사람이 읽을 수 있는 텍스트입니다.
      manualRules	이름 및 이유 쌍 목록입니다. 수동 규칙이 추가되면 검사 결과 상태가 항상 수동 이 되고 수정 사항이 생성되지 않습니다. 이 속성은 자동이며 기본적으로 수동 규칙으로 설정할 때 값이 없습니다.
      enableRules	이름 및 이유 쌍 목록입니다. 각 이름은 활성화할 규칙 오브젝트의 이름을 나타냅니다. 이유 값은 규칙이 활성화된 이유를 설명하는 사람이 읽을 수 있는 텍스트입니다.
      description	TailoredProfile을 설명하는 사람이 읽을 수 있는 텍스트입니다.
      setValues	이름, 이유 및 값 그룹화 목록입니다. 각 이름은 설정된 값의 이름을 나타냅니다. 이유는 집합을 설명하는 사람이 읽을 수 있는 텍스트입니다. 값은 실제 설정입니다.

   2. tailoredProfile.spec.manualRules 속성을 추가합니다.

      예제 tailoredProfile.spec.manualRules.yaml

      apiVersion: compliance.openshift.io/v1alpha1
      kind: TailoredProfile
      metadata:
        name: ocp4-manual-scc-check
      spec:
        extends: ocp4-cis
        description: This profile extends ocp4-cis by forcing the SCC check to always return MANUAL
        title: OCP4 CIS profile with manual SCC check
        manualRules:
          - name: ocp4-scc-limit-container-allowed-capabilities
            rationale: We use third party software that installs its own SCC with extra privileges

   3. TailoredProfile 오브젝트를 생성합니다.

      $ oc create -n openshift-compliance -f new-profile-node.yaml 1

      1

      TailoredProfile 오브젝트는 기본 openshift-compliance 네임스페이스에 생성됩니다.

      출력 예

      tailoredprofile.compliance.openshift.io/nist-moderate-modified created

4. 새 nist-moderate-modified 맞춤형 프로필을 기본 ScanSetting 오브젝트에 바인딩하도록 ScanSettingBinding 오브젝트를 정의합니다.

   예제 new-scansettingbinding.yaml

   apiVersion: compliance.openshift.io/v1alpha1
   kind: ScanSettingBinding
   metadata:
     name: nist-moderate-modified
   profiles:
     - apiGroup: compliance.openshift.io/v1alpha1
       kind: Profile
       name: ocp4-moderate
     - apiGroup: compliance.openshift.io/v1alpha1
       kind: TailoredProfile
       name: nist-moderate-modified
   settingsRef:
     apiGroup: compliance.openshift.io/v1alpha1
     kind: ScanSetting
     name: default

5. ScanSettingBinding 오브젝트를 생성합니다.

   $ oc create -n openshift-compliance -f new-scansettingbinding.yaml

   출력 예

   scansettingbinding.compliance.openshift.io/nist-moderate-modified created

1. ComplianceSuite 오브젝트를 살펴봅니다.

   $ oc get compliancesuites nist-moderate-modified \
   -o json -n openshift-compliance | jq '.status.scanStatuses[].resultsStorage'

   출력 예

   {
        "name": "ocp4-moderate",
        "namespace": "openshift-compliance"
   }
   {
        "name": "nist-moderate-modified-master",
        "namespace": "openshift-compliance"
   }
   {
        "name": "nist-moderate-modified-worker",
        "namespace": "openshift-compliance"
   }

   원시 결과에 액세스할 수 있는 영구 볼륨 클레임이 표시됩니다.

2. 결과 중 하나의 이름과 네임스페이스를 사용하여 원시 데이터 위치를 확인합니다.

   $ oc get pvc -n openshift-compliance rhcos4-moderate-worker

   출력 예

   NAME                 	STATUS   VOLUME                                 	CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   rhcos4-moderate-worker   Bound	pvc-548f6cfe-164b-42fe-ba13-a07cfbc77f3a   1Gi    	RWO        	gp2        	92m

3. 볼륨을 마운트하는 Pod를 생성하고 결과를 복사하여 원시 결과를 가져옵니다.

   $ oc create -n openshift-compliance -f pod.yaml

   pod.yaml의 예

   apiVersion: "v1"
   kind: Pod
   metadata:
     name: pv-extract
   spec:
     containers:
       - name: pv-extract-pod
         image: registry.access.redhat.com/ubi9/ubi
         command: ["sleep", "3000"]
         volumeMounts:
         - mountPath: "/workers-scan-results"
           name: workers-scan-vol
     volumes:
       - name: workers-scan-vol
         persistentVolumeClaim:
           claimName: rhcos4-moderate-worker

4. Pod가 실행되면 결과를 다운로드합니다.

   $ oc cp pv-extract:/workers-scan-results -n openshift-compliance .

   중요

   영구 볼륨을 마운트하는 Pod를 생성하면 클레임이 Bound로 유지됩니다. 사용 중인 볼륨의 스토리지 클래스에 ReadWriteOnce로 설정된 권한이 있는 경우 한 번에 하나의 Pod에서만 볼륨을 마운트할 수 있습니다. 완료 시 Pod를 삭제해야 합니다. 그러지 않으면 Operator에서 Pod를 예약하고 이 위치에 결과를 계속 저장할 수 없습니다.

5. 추출이 완료되면 Pod를 삭제할 수 있습니다.

   $ oc delete pod pv-extract -n openshift-compliance

프로세스

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.27.3
   ip-10-0-158-32.us-east-2.compute.internal  Ready   worker 5h17m  v1.27.3
   ip-10-0-166-81.us-east-2.compute.internal  Ready   worker 5h17m  v1.27.3
   ip-10-0-171-170.us-east-2.compute.internal Ready   master 5h21m  v1.27.3
   ip-10-0-197-35.us-east-2.compute.internal  Ready   master 5h22m  v1.27.3

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(Machine config pool)에 추가할 레이블 이름을 정의합니다.

4. MCP가 성공적으로 생성되었는지 확인합니다.

   $ oc get mcp -w

프로세스

1. 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 * * *'

2. 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
   settingsRef:
     apiGroup: compliance.openshift.io/v1alpha1
     kind: ScanSetting
     name: default

프로세스

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=

프로세스

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

프로세스

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 오브젝트가 수정을 포함하지 않도록 다시 렌더링됩니다.

   중요

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

프로세스

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.available,nodefs.available,nodefs.inodesFree,imagefs.available, imagefs.inodesFree 를 지정해야 합니다. 모든 매개변수를 지정하지 않으면 지정된 매개변수만 적용되고 수정이 제대로 작동하지 않습니다.

2. 수정을 제거합니다.

   1. 수정 오브젝트에 대해 apply to 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

      중요

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

프로세스

1. 파일에서 ConfigMap 오브젝트를 만듭니다.

   $ oc -n openshift-compliance \
   create configmap nist-moderate-modified \
   --from-file=tailoring.xml=/path/to/the/tailoringFile.xml

2. 모음에 속하는 검사의 맞춤 파일을 참조합니다.

   apiVersion: compliance.openshift.io/v1alpha1
   kind: ComplianceSuite
   metadata:
     name: workers-compliancesuite
   spec:
     debug: true
     scans:
       - name: workers-scan
         profile: xccdf_org.ssgproject.content_profile_moderate
         content: ssg-rhcos4-ds.xml
         contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc...
         debug: true
     tailoringConfigMap:
         name: nist-moderate-modified
     nodeSelector:
       node-role.kubernetes.io/worker: ""

프로세스

1. 이름이 restricted-adjusted-compliance.yaml 인 YAML 파일에 SCC를 정의합니다.

   SecurityContextConstraints 오브젝트 정의

     allowHostDirVolumePlugin: false
     allowHostIPC: false
     allowHostNetwork: false
     allowHostPID: false
     allowHostPorts: false
     allowPrivilegeEscalation: true
     allowPrivilegedContainer: false
     allowedCapabilities: null
     apiVersion: security.openshift.io/v1
     defaultAddCapabilities: null
     fsGroup:
       type: MustRunAs
     kind: SecurityContextConstraints
     metadata:
       name: restricted-adjusted-compliance
     priority: 30 1
     readOnlyRootFilesystem: false
     requiredDropCapabilities:
     - KILL
     - SETUID
     - SETGID
     - MKNOD
     runAsUser:
       type: MustRunAsRange
     seLinuxContext:
       type: MustRunAs
     supplementalGroups:
       type: RunAsAny
     users:
     - system:serviceaccount:openshift-compliance:api-resource-collector 2
     volumes:
     - configMap
     - downwardAPI
     - emptyDir
     - persistentVolumeClaim
     - projected
     - secret

   1

   이 SCC의 우선순위는 system:authenticated 그룹에 적용되는 다른 SCC보다 커야 합니다.

   2

   Compliance Operator 스캐너 Pod에서 사용하는 서비스 계정입니다.

2. SCC를 생성합니다.

   $ oc create -n openshift-compliance  -f restricted-adjusted-compliance.yaml

   출력 예

   securitycontextconstraints.security.openshift.io/restricted-adjusted-compliance created

검증

1. SCC가 생성되었는지 확인합니다.

   $ oc get -n openshift-compliance scc restricted-adjusted-compliance

   출력 예

   NAME                             PRIV    CAPS         SELINUX     RUNASUSER        FSGROUP     SUPGROUP   PRIORITY   READONLYROOTFS   VOLUMES
   restricted-adjusted-compliance   false   <no value>   MustRunAs   MustRunAsRange   MustRunAs   RunAsAny   30         false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]

프로세스

1. Operator의 메모리 제한을 500Mi로 늘리려면 co-memlimit-patch.yaml 이라는 다음 패치 파일을 생성합니다.

   spec:
     config:
       resources:
         limits:
           memory: 500Mi

2. 패치 파일을 적용합니다.

   $ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge

프로세스

1. ocp4-pci-dss-api-checks-pod Pod가 Init:OOMKilled 상태에 있는지 확인합니다.

   $ oc get pod ocp4-pci-dss-api-checks-pod -w

   출력 예

   NAME                          READY   STATUS     RESTARTS        AGE
   ocp4-pci-dss-api-checks-pod   0/2     Init:1/2   8 (5m56s ago)   25m
   ocp4-pci-dss-api-checks-pod   0/2     Init:OOMKilled   8 (6m19s ago)   26m

2. ScanSetting CR에서 scanLimits 속성을 편집하여 ocp4-pci-dss-api-checks-pod Pod에 사용 가능한 메모리를 늘립니다.

   timeout: 30m
   strictNodeScan: true
   metadata:
     name: default
     namespace: openshift-compliance
   kind: ScanSetting
   showNotApplicable: false
   rawResultStorage:
     nodeSelector:
       node-role.kubernetes.io/master: ''
     pvAccessModes:
       - ReadWriteOnce
     rotation: 3
     size: 1Gi
     tolerations:
       - effect: NoSchedule
         key: node-role.kubernetes.io/master
         operator: Exists
       - effect: NoExecute
         key: node.kubernetes.io/not-ready
         operator: Exists
         tolerationSeconds: 300
       - effect: NoExecute
         key: node.kubernetes.io/unreachable
         operator: Exists
         tolerationSeconds: 300
       - effect: NoSchedule
         key: node.kubernetes.io/memory-pressure
         operator: Exists
   schedule: 0 1 * * *
   roles:
     - master
     - worker
   apiVersion: compliance.openshift.io/v1alpha1
   maxRetryOnTimeout: 3
   scanTolerations:
     - operator: Exists
   scanLimits:
     memory: 1024Mi 1

   1

   기본 설정은 500Mi 입니다.

3. ScanSetting CR을 클러스터에 적용합니다.

   $ oc apply -f scansetting.yaml

프로세스

1. oc-compliance 이미지를 추출하여 oc-compliance 바이너리를 가져옵니다.

   $ podman run --rm -v ~/.local/bin:/mnt/out:Z registry.redhat.io/compliance/oc-compliance-rhel8:stable /bin/cp /usr/bin/oc-compliance /mnt/out/

   출력 예

   W0611 20:35:46.486903   11354 manifest.go:440] Chose linux/amd64 manifest from the manifest list.

   이제 oc-compliance를 실행할 수 있습니다.

프로세스

1. 다음을 실행합니다.

   $ oc compliance bind [--dry-run] -N <binding name> [-S <scansetting name>] <objtype/objname> [..<objtype/objname>]

   • -S 플래그를 생략하면 Compliance Operator에서 제공하는 default 검사 설정이 사용됩니다.
   • 오브젝트 유형은 Kubernetes 오브젝트 유형으로 profile 또는 tailoredprofile 일 수 있습니다. 두 개 이상의 오브젝트를 제공할 수 있습니다.
   • 오브젝트 이름은 Kubernetes 리소스의 이름입니다 (예: .metadata.name).

   • --dry-run 옵션을 추가하여 생성된 오브젝트의 YAML 파일을 표시합니다.

     예를 들어 다음 프로필 및 검사 설정이 제공됩니다.

     $ oc get profile.compliance -n openshift-compliance

     출력 예

     NAME                       AGE     VERSION
     ocp4-cis                   3h49m   1.5.0
     ocp4-cis-1-4               3h49m   1.4.0
     ocp4-cis-1-5               3h49m   1.5.0
     ocp4-cis-node              3h49m   1.5.0
     ocp4-cis-node-1-4          3h49m   1.4.0
     ocp4-cis-node-1-5          3h49m   1.5.0
     ocp4-e8                    3h49m
     ocp4-high                  3h49m   Revision 4
     ocp4-high-node             3h49m   Revision 4
     ocp4-high-node-rev-4       3h49m   Revision 4
     ocp4-high-rev-4            3h49m   Revision 4
     ocp4-moderate              3h49m   Revision 4
     ocp4-moderate-node         3h49m   Revision 4
     ocp4-moderate-node-rev-4   3h49m   Revision 4
     ocp4-moderate-rev-4        3h49m   Revision 4
     ocp4-nerc-cip              3h49m
     ocp4-nerc-cip-node         3h49m
     ocp4-pci-dss               3h49m   3.2.1
     ocp4-pci-dss-3-2           3h49m   3.2.1
     ocp4-pci-dss-4-0           3h49m   4.0.0
     ocp4-pci-dss-node          3h49m   3.2.1
     ocp4-pci-dss-node-3-2      3h49m   3.2.1
     ocp4-pci-dss-node-4-0      3h49m   4.0.0
     ocp4-stig                  3h49m   V2R1
     ocp4-stig-node             3h49m   V2R1
     ocp4-stig-node-v1r1        3h49m   V1R1
     ocp4-stig-node-v2r1        3h49m   V2R1
     ocp4-stig-v1r1             3h49m   V1R1
     ocp4-stig-v2r1             3h49m   V2R1
     rhcos4-e8                  3h49m
     rhcos4-high                3h49m   Revision 4
     rhcos4-high-rev-4          3h49m   Revision 4
     rhcos4-moderate            3h49m   Revision 4
     rhcos4-moderate-rev-4      3h49m   Revision 4
     rhcos4-nerc-cip            3h49m
     rhcos4-stig                3h49m   V2R1
     rhcos4-stig-v1r1           3h49m   V1R1
     rhcos4-stig-v2r1           3h49m   V2R1

     $ oc get scansettings -n openshift-compliance

     출력 예

     NAME                 AGE
     default              10m
     default-auto-apply   10m

2. default 설정을 ocp4-cis 및 ocp4-cis-node 프로필에 적용하려면 다음을 실행합니다.

   $ oc compliance bind -N my-binding profile/ocp4-cis profile/ocp4-cis-node

   출력 예

   Creating ScanSettingBinding my-binding

   ScanSettingBinding CR이 생성되면 바인딩된 프로파일은 관련 설정으로 두 프로필의 스캔을 시작합니다. 전반적으로 이것은 Compliance Operator로 스캔을 시작하는 가장 빠른 방법입니다.

프로세스

1. 프로필의 수정을 확인합니다.

   $ oc compliance fetch-fixes profile ocp4-cis -o /tmp

   출력 예

   No fixes to persist for rule 'ocp4-api-server-api-priority-flowschema-catch-all' 1
   No fixes to persist for rule 'ocp4-api-server-api-priority-gate-enabled'
   No fixes to persist for rule 'ocp4-api-server-audit-log-maxbackup'
   Persisted rule fix to /tmp/ocp4-api-server-audit-log-maxsize.yaml
   No fixes to persist for rule 'ocp4-api-server-audit-log-path'
   No fixes to persist for rule 'ocp4-api-server-auth-mode-no-aa'
   No fixes to persist for rule 'ocp4-api-server-auth-mode-node'
   No fixes to persist for rule 'ocp4-api-server-auth-mode-rbac'
   No fixes to persist for rule 'ocp4-api-server-basic-auth'
   No fixes to persist for rule 'ocp4-api-server-bind-address'
   No fixes to persist for rule 'ocp4-api-server-client-ca'
   Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-cipher.yaml
   Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-config.yaml

   1

   규칙을 자동으로 수정할 수 없거나 수정이 제공되지 않았기 때문에 프로필에 해당 수정 조치가 없는 규칙이 있을 때마다 No fixes to persist 경고가 예상됩니다.

2. YAML 파일의 샘플을 볼 수 있습니다. head 명령은 처음 10행을 표시합니다.

   $ head /tmp/ocp4-api-server-audit-log-maxsize.yaml

   출력 예

   apiVersion: config.openshift.io/v1
   kind: APIServer
   metadata:
     name: cluster
   spec:
     maximumFileSizeMegabytes: 100

3. 검사 후 생성된 ComplianceRemediation 오브젝트에서 수정을 확인합니다.

   $ oc get complianceremediations -n openshift-compliance

   출력 예

   NAME                                             STATE
   ocp4-cis-api-server-encryption-provider-cipher   NotApplied
   ocp4-cis-api-server-encryption-provider-config   NotApplied

   $ oc compliance fetch-fixes complianceremediations ocp4-cis-api-server-encryption-provider-cipher -o /tmp

   출력 예

   Persisted compliance remediation fix to /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml

4. YAML 파일의 샘플을 볼 수 있습니다. head 명령은 처음 10행을 표시합니다.

   $ head /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml

   출력 예

   apiVersion: config.openshift.io/v1
   kind: APIServer
   metadata:
     name: cluster
   spec:
     encryption:
       type: aescbc