5.5. Compliance Operator 검사
Compliance Operator를 사용하여 규정 준수 검사를 실행하도록 ScanSetting
및 ScanSettingBinding
API를 사용하는 것이 좋습니다. 이러한 API 오브젝트에 대한 자세한 내용을 보려면 다음을 실행합니다.
$ oc explain scansettings
또는
$ oc explain scansettingbindings
5.5.1. 규정 준수 검사 실행
CIS(Center for Internet Security) 프로필을 사용하여 검사를 실행할 수 있습니다. 편의를 위해 Compliance Operator는 시작 시 적절한 기본값을 사용하여 ScanSetting
오브젝트를 생성합니다. 이 ScanSetting
오브젝트의 이름은 default
입니다.
올인원 컨트롤 플레인 및 작업자 노드의 경우 규정 준수 스캔은 작업자 및 컨트롤 플레인 노드에서 두 번 실행됩니다. 규정 준수 검사에서 일관되지 않은 검사 결과를 생성할 수 있습니다. ScanSetting
오브젝트에서 단일 역할만 정의하여 일관성 없는 결과를 방지할 수 있습니다.
프로세스
다음을 실행하여
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 Metadata: Creation Timestamp: 2022-10-10T14:07:29Z Generation: 1 Managed Fields: API Version: compliance.openshift.io/v1alpha1 Fields Type: FieldsV1 fieldsV1: 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-10T14:07:29Z Resource Version: 56111 UID: c21d1d14-3472-47d7-a450-b924287aec90 Raw Result Storage: Node Selector: node-role.kubernetes.io/master: Pv Access Modes: ReadWriteOnce 1 Rotation: 3 2 Size: 1Gi 3 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 4 worker 5 Scan Tolerations: 6 Operator: Exists Schedule: 0 1 * * * 7 Show Not Applicable: false Strict Node Scan: true 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 5
- 검사 설정에서 클러스터 노드를 검사하는 프로필을 사용하는 경우 이러한 노드 역할을 검사합니다.
- 6
- 기본 검사 설정 오브젝트는 모든 노드를 검사합니다.
- 7
- 기본 검사 설정 오브젝트는 매일 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 Auto Update Remediations: true 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: 1 f:autoUpdateRemediations: 2 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>
기본
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
다음을 실행하여
ScanSettingBinding
오브젝트를 생성합니다.$ oc create -f <file-name>.yaml -n openshift-compliance
프로세스의 이 시점에서
ScanSettingBinding
오브젝트는Binding
및Bound
설정을 기반으로 조정됩니다. Compliance Operator는ComplianceSuite
오브젝트 및 관련ComplianceScan
오브젝트를 생성합니다.다음을 실행하여 컴플라이언스 검사 진행 상황을 따르십시오.
$ oc get compliancescan -w -n openshift-compliance
검사는 스캔 단계를 통해 진행되며 완료되면
DONE
단계에 도달합니다. 대부분의 경우 검사 결과는NON-COMPLIANT
입니다. 검사 결과를 검토하고 업데이트 적용 작업을 시작하여 클러스터를 준수하도록 할 수 있습니다. 자세한 내용은 Compliance Operator 업데이트 적용 관리를 참조하십시오.
5.5.2. 작업자 노드에서 결과 서버 Pod 예약
결과 서버 포드는 raw Asset Reporting Format(ARF) 검사 결과를 저장하는 PV(영구 볼륨)를 마운트합니다. nodeSelector
및 허용 오차
특성을 사용하면 결과 서버 Pod의 위치를 구성할 수 있습니다.
이 기능은 컨트롤 플레인 노드가 영구 볼륨 마운트를 허용하지 않는 환경에서 유용합니다.
프로세스
Compliance Operator에 대한
ScanSetting
CR(사용자 정의 리소스)을 생성합니다.ScanSetting
CR을 정의하고 YAML 파일(예:rs-workers.yaml)을 저장합니다.
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: rs-on-workers namespace: openshift-compliance rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" 1 pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists 2 roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * *
ScanSetting
CR을 생성하려면 다음 명령을 실행합니다.$ oc create -f rs-workers.yaml
검증
ScanSetting
오브젝트가 생성되었는지 확인하려면 다음 명령을 실행합니다.$ oc get scansettings rs-on-workers -n openshift-compliance -o yaml
출력 예
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: creationTimestamp: "2021-11-19T19:36:36Z" generation: 1 name: rs-on-workers namespace: openshift-compliance resourceVersion: "48305" uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * * strictNodeScan: true
5.5.3. ScanSetting
사용자 정의 리소스
이제 ScanSetting
사용자 정의 리소스를 사용하면 검사 제한 특성을 통해 스캐너 Pod의 기본 CPU 및 메모리 제한을 덮어쓸 수 있습니다. Compliance Operator는 기본값 500Mi 메모리, 스캐너 컨테이너에 100m CPU, api-resource-collector
컨테이너에 100m CPU가 있는 200Mi 메모리를 사용합니다. Operator의 메모리 제한을 설정하려면 OLM 또는 Operator 배포 자체를 통해 설치한 경우 Subscription
오브젝트를 수정합니다.
Compliance Operator의 기본 CPU 및 메모리 제한을 늘리려면 Compliance Operator 리소스 제한 증가를 참조하십시오.
기본 제한이 충분하지 않고 OOM(메모리 부족) 프로세스에서 Operator 또는 스캐너 Pod를 종료하는 경우 Compliance Operator 또는 scanner Pod에 대한 메모리 제한을 늘려야 합니다.
5.5.4. 리소스 요청 및 제한 적용
kubelet이 컨테이너를 Pod의 일부로 시작하면 kubelet은 해당 컨테이너의 요청과 메모리 및 CPU에 대한 제한을 컨테이너 런타임으로 전달합니다. Linux에서 컨테이너 런타임은 사용자가 정의한 제한을 적용하고 적용하는 커널 cgroup을 구성합니다.
CPU 제한은 컨테이너에서 사용할 수 있는 CPU 시간을 정의합니다. 각 스케줄링 간격 동안 Linux 커널은 이 제한이 초과되었는지 확인합니다. 이 경우 커널은 cgroup 실행을 재개할 때까지 기다립니다.
contended 시스템에서 여러 개의 다른 컨테이너(cgroups)를 실행하려는 경우 CPU 요청이 큰 워크로드에 작은 요청이 있는 워크로드보다 더 많은 CPU 시간이 할당됩니다. 메모리 요청은 Pod 예약 중에 사용됩니다. cgroup v2를 사용하는 노드에서 컨테이너 런타임은 메모리 요청을 힌트로 사용하여 memory.min
및 memory.low
값을 설정할 수 있습니다.
컨테이너가 이 제한보다 많은 메모리를 할당하려고 하면 Linux 커널 메모리 부족 하위 시스템은 메모리를 할당하려는 컨테이너의 프로세스 중 하나를 중지하여 활성화 및 개입합니다. Pod 또는 컨테이너의 메모리 제한은 emptyDir과 같은 메모리 지원 볼륨의 페이지에도 적용할 수 있습니다.
kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리가 사용되므로 tmpfs
emptyDir
볼륨을 추적합니다. 컨테이너가 메모리 요청을 초과하고 실행 중인 노드가 총 메모리가 부족하면 Pod의 컨테이너가 제거될 수 있습니다.
컨테이너는 연장된 기간에 CPU 제한을 초과할 수 없습니다. 컨테이너 실행 시간은 과도한 CPU 사용을 위한 Pod 또는 컨테이너를 중지하지 않습니다. 리소스 제한으로 인해 컨테이너를 예약할 수 없거나 종료될 수 없는지 확인하려면 Compliance Operator 문제 해결을 참조하십시오.
5.5.5. 컨테이너 리소스 요청을 사용하여 Pod 예약
Pod가 생성되면 스케줄러는 Pod를 실행할 노드를 선택합니다. 각 노드에는 Pod에 제공할 수 있는 CPU 및 메모리 양에서 각 리소스 유형에 대한 최대 용량이 있습니다. 스케줄러는 예약된 컨테이너의 리소스 요청 합계가 각 리소스 유형의 용량 노드보다 작은지 확인합니다.
노드의 메모리 또는 CPU 리소스 사용량이 매우 낮지만 용량 검사에서 노드의 리소스 부족으로부터 보호하지 못하는 경우에도 스케줄러에서 노드에 Pod를 배치하지 못할 수 있습니다.
각 컨테이너에서 다음 리소스 제한 및 요청을 지정할 수 있습니다.
spec.containers[].resources.limits.cpu spec.containers[].resources.limits.memory spec.containers[].resources.limits.hugepages-<size> spec.containers[].resources.requests.cpu spec.containers[].resources.requests.memory spec.containers[].resources.requests.hugepages-<size>
개별 컨테이너에만 요청 및 제한을 지정할 수 있지만 Pod에 대한 전체 리소스 요청 및 제한을 고려하는 것도 유용합니다. 특정 리소스에 대한 컨테이너 리소스 요청 또는 제한은 Pod의 각 컨테이너에 대한 해당 유형의 리소스 요청 또는 제한의 합계입니다.
컨테이너 리소스 요청 및 제한의 예
apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: 1 memory: "64Mi" cpu: "250m" limits: 2 memory: "128Mi" cpu: "500m" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"