5.12. Compliance Operator 문제 해결
이 섹션에서는 Compliance Operator 문제 해결 방법에 대해 설명합니다. 이 정보는 문제를 진단하거나 버그 보고서에 정보를 제공하는 데 유용할 수 있습니다. 몇 가지 일반적인 정보:
Compliance Operator는 중요한 일이 발생할 때 Kubernetes 이벤트를 생성합니다. 다음 명령을 사용하여 클러스터의 모든 이벤트를 볼 수 있습니다.
$ oc get events -n openshift-compliance
또는 다음 명령을 사용하여 검사와 같은 오브젝트 이벤트를 볼 수 있습니다.
$ oc describe -n openshift-compliance compliancescan/cis-compliance
Compliance Operator는 대략 API 오브젝트당 하나씩 여러 개의 컨트롤러로 구성됩니다. 문제가 있는 API 오브젝트에 해당하는 컨트롤러만 필터링하는 것이 유용할 수 있습니다.
ComplianceRemediation
을 적용할 수 없는 경우remediationctrl
컨트롤러의 메시지를 확인하십시오.jq
를 사용하여 구문 분석하면 단일 컨트롤러의 메시지를 필터링할 수 있습니다.$ oc -n openshift-compliance logs compliance-operator-775d7bddbd-gj58f \ | jq -c 'select(.logger == "profilebundlectrl")'
타임스탬프는 UTC의 UNIX epoch 이후의 초로 기록됩니다. 사람이 읽을 수 있는 날짜로 변환하려면
date -d @timestamp --utc
를 사용하십시오. 예를 들면 다음과 같습니다.$ date -d @1596184628.955853 --utc
-
많은 사용자 정의 리소스 중에서도 가장 중요한
ComplianceSuite
및ScanSetting
에서는debug
옵션을 설정할 수 있습니다. 이 옵션을 활성화하면 OpenSCAP 스캐너 Pod 및 기타 도우미 Pod의 상세 수준이 높아집니다. -
단일 규칙이 예기치 않게 통과 또는 실패하는 경우 해당 규칙만 사용하여 단일 스캔 또는 모음을 실행하고 해당
ComplianceCheckResult
오브젝트에서 규칙 ID를 찾은 후 이를Scan
CR에서rule
특성 값으로 사용하는 것이 도움이 될 수 있습니다. 그러면debug
옵션이 활성화된 상태에서 스캐너 Pod의scanner
컨테이너 로그에 원시 OpenSCAP 로그가 표시됩니다.
5.12.1. 검사 구조
다음 섹션에서는 Compliance Operator 검사의 구성 요소 및 단계를 간략하게 설명합니다.
5.12.1.1. 규정 준수 소스
규정 준수 콘텐츠는 ProfileBundle
오브젝트에서 생성되는 Profile
오브젝트에 저장됩니다. Compliance Operator는 클러스터와 클러스터 노드에 대해 각각 하나의 ProfileBundle
오브젝트를 생성합니다.
$ oc get -n openshift-compliance profilebundle.compliance
$ oc get -n openshift-compliance profile.compliance
ProfileBundle
오브젝트는 Bundle
이라는 이름으로 레이블이 지정된 배포에서 처리합니다. Bundle
문제를 해결하려면 배포를 찾은 후 해당 배포에서 Pod 로그를 보면 됩니다.
$ oc logs -n openshift-compliance -lprofile-bundle=ocp4 -c profileparser
$ oc get -n openshift-compliance deployments,pods -lprofile-bundle=ocp4
$ oc logs -n openshift-compliance pods/<pod-name>
$ oc describe -n openshift-compliance pod/<pod-name> -c profileparser
5.12.1.2. ScanSetting 및 ScanSettingBinding 오브젝트 라이프사이클 및 디버깅
유효한 준수 콘텐츠 소스를 사용하면 높은 수준의 ScanSetting
및 ScanSettingBinding
오브젝트를 사용하여 ComplianceSuite
및 ComplianceScan
오브젝트를 생성할 수 있습니다.
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: my-companys-constraints debug: true # For each role, a separate scan will be created pointing # to a node-role specified in roles roles: - worker --- apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: my-companys-compliance-requirements profiles: # Node checks - name: rhcos4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 # Cluster checks - name: ocp4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: my-companys-constraints kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1
ScanSetting
및 ScanSettingBinding
오브젝트는 모두 logger=scansettingbindingctrl
태그가 지정된 동일한 컨트롤러에서 처리합니다. 이러한 오브젝트에는 상태가 없습니다. 모든 문제는 이벤트 형식으로 전달됩니다.
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuiteCreated 9m52s scansettingbindingctrl ComplianceSuite openshift-compliance/my-companys-compliance-requirements created
이제 ComplianceSuite
오브젝트가 생성되었습니다. flow는 새로 생성된 ComplianceSuite
를 계속 조정합니다.
5.12.1.3. ComplianceSuite 사용자 정의 리소스 라이프사이클 및 디버깅
ComplianceSuite
CR은 ComplianceScan
관련 래퍼입니다. ComplianceSuite
CR은 logger=suitectrl
태그가 지정된 컨트롤러에서 처리합니다. 이 컨트롤러는 모음의 검사 생성을 처리하고 개별 검사 상태를 단일 모음 상태로 조정 및 집계합니다. 모음이 주기적으로 실행되도록 설정된 경우에는 초기 실행이 완료된 후 suitectrl
에서도 CronJob
CR 생성을 처리합니다.
$ oc get cronjobs
출력 예
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE <cron_name> 0 1 * * * False 0 <none> 151m
가장 중요한 문제의 경우 이벤트가 생성됩니다. oc describe compliancesuites/<name>
으로 문제를 확인하십시오. Suite
오브젝트에는 이 모음에 속한 Scan
오브젝트에서 Status
하위 리소스를 업데이트할 때 업데이트되는 Status
하위 리소스도 있습니다. 예상되는 모든 검사가 생성되면 제어가 검사 컨트롤러로 전달됩니다.
5.12.1.4. ComplianceScan 사용자 정의 리소스 라이프사이클 및 디버깅
ComplianceScan
CR은 scanctrl
컨트롤러에 의해 처리됩니다. 여기에서 실제 검사가 발생하고 검사 결과가 생성됩니다. 각 검사는 여러 단계를 거칩니다.
5.12.1.4.1. 보류 단계
이 단계에서는 검사의 정확성을 확인합니다. 스토리지 크기와 같은 일부 매개변수가 잘못된 경우 검사가 ‘오류와 함께 완료’ 결과로 전환되고, 그러지 않으면 시작 단계가 진행됩니다.
5.12.1.4.2. 시작 단계
이 단계에서는 스캐너 Pod에 대한 환경이나 스캐너 Pod를 평가할 스크립트를 직접 포함하는 여러 구성 맵이 있습니다. 구성 맵을 나열합니다.
$ oc -n openshift-compliance get cm \ -l compliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=
이러한 구성 맵은 스캐너 Pod에서 사용합니다. 스캐너 동작을 수정하거나 스캐너 디버그 수준을 변경하거나 원시 결과를 출력해야 하는 경우 구성 맵을 수정하는 것이 좋습니다. 이후 원시 ARF 결과를 저장하기 위해 검사별 영구 볼륨 클레임이 생성됩니다.
$ oc get pvc -n openshift-compliance -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
PVC는 검사별 ResultServer
배포로 마운트됩니다. ResultServer
는 개별 스캐너 Pod에서 전체 ARF 결과를 업로드하는 간단한 HTTP 서버입니다. 각 서버는 다른 노드에서 실행될 수 있습니다. 전체 ARF 결과는 매우 클 수 있으며 동시에 여러 노드에서 마운트할 수 있는 볼륨을 생성할 수 있다고 가정해서는 안 됩니다. 검사가 완료되면 ResultServer
배포가 축소됩니다. 원시 결과가 있는 PVC는 다른 사용자 정의 Pod에서 마운트할 수 있으며 결과를 가져오거나 검사할 수 있습니다. 스캐너 Pod와 ResultServer
간 트래픽은 상호 TLS 프로토콜로 보호됩니다.
마지막으로 이 단계에서는 스캐너 Pod가 시작되는데, Platform
검사 인스턴스용 스캐너 Pod 1개와 node
검사 인스턴스에 일치하는 노드당 스캐너 Pod 1개입니다. 노드별 Pod는 노드 이름으로 레이블이 지정됩니다. 각 Pod는 항상 ComplianceScan
이라는 이름으로 레이블이 지정됩니다.
$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels
출력 예
NAME READY STATUS RESTARTS AGE LABELS rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod 0/2 Completed 0 39m compliance.openshift.io/scan-name=rhcos4-e8-worker,targetNode=ip-10-0-169-90.eu-north-1.compute.internal,workload=scanner
+ 검사는 실행 중 단계로 진행됩니다.
5.12.1.4.3. 실행 단계
실행 단계는 스캐너 Pod가 종료될 때까지 대기합니다. 다음은 실행 단계에서 사용되는 용어 및 프로세스입니다.
-
Init 컨테이너:
content-container
라는 하나의 init 컨테이너가 있습니다. contentImage 컨테이너를 실행하고 이 Pod의 다른 컨테이너와 공유하는/content
디렉터리에 contentFile을 복사하는 단일 명령을 실행합니다. -
scanner: 이 컨테이너는 스캔을 실행합니다. 노드 검사의 경우 컨테이너는 노드 파일 시스템을
/host
로 마운트하고 init 컨테이너에서 제공하는 콘텐츠를 마운트합니다. 컨테이너는 또한 시작 단계에서 생성된entrypoint
ConfigMap
을 마운트하고 실행합니다. 진입점ConfigMap
의 기본 스크립트는 OpenSCAP을 실행하고 Pod 컨테이너 간 공유하는/results
디렉터리에 결과 파일을 저장합니다. 이 Pod의 로그를 보고 OpenSCAP 스캐너에서 점검한 사항을 확인할 수 있습니다. 더 자세한 출력 내용은debug
플래그를 사용하여 볼 수 있습니다. logcollector: logcollector 컨테이너는 scanner 컨테이너가 종료될 때까지 기다립니다. 그런 다음 전체 ARF 결과를
ResultServer
에 업로드하고 XCCDF 결과를 검사 결과 및 OpenSCAP 결과 코드와 함께ConfigMap
으로 별도로 업로드합니다. 이러한 결과 구성 맵은 검사 이름(compliance.openshift.io/scan-name=rhcos4-e8-worker
)으로 레이블이 지정됩니다.$ oc describe cm/rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod
출력 예
Name: rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod Namespace: openshift-compliance Labels: compliance.openshift.io/scan-name-scan=rhcos4-e8-worker complianceoperator.openshift.io/scan-result= Annotations: compliance-remediations/processed: compliance.openshift.io/scan-error-msg: compliance.openshift.io/scan-result: NON-COMPLIANT OpenSCAP-scan-result/node: ip-10-0-169-90.eu-north-1.compute.internal Data ==== exit-code: ---- 2 results: ---- <?xml version="1.0" encoding="UTF-8"?> ...
Platform
검사를 위한 스캐너 Pod는 다음을 제외하고 비슷합니다.
-
api-resource-collector
라는 하나의 추가 init 컨테이너가 있습니다. 이 컨테이너는 content-container init 컨테이너에서 제공하는 OpenSCAP 콘텐츠를 읽고, 해당 콘텐츠에서 검사해야 하는 API 리소스를 파악한 후scanner
컨테이너에서 이러한 API 리소스를 읽는 공유 디렉터리에 저장합니다. -
scanner
컨테이너는 호스트 파일 시스템을 마운트할 필요가 없습니다.
스캐너 Pod가 완료되면 검사가 집계 단계로 이동합니다.
5.12.1.4.4. 집계 단계
검사 컨트롤러는 집계 단계에서 집계기 Pod라는 또 다른 Pod를 생성합니다. 그 목적은 결과 ConfigMap
오브젝트를 가져와서 결과를 읽고 각 점검 결과에 해당하는 Kubernetes 오브젝트를 만드는 것입니다. 점검 실패를 자동으로 수정할 수 있는 경우 ComplianceRemediation
오브젝트가 생성됩니다. 또한 집계기 Pod는 사람이 읽을 수 있는 점검 및 수정용 메타데이터를 제공하기 위해 init 컨테이너를 사용하여 OpenSCAP 콘텐츠도 마운트합니다.
집계기 Pod에서 구성 맵을 처리하면 구성 맵에 compliance-remediations/processed
라는 레이블이 지정됩니다. 이 단계의 결과는 ComplianceCheckResult
오브젝트
$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
출력 예
NAME STATUS SEVERITY rhcos4-e8-worker-accounts-no-uid-except-zero PASS high rhcos4-e8-worker-audit-rules-dac-modification-chmod FAIL medium
및 ComplianceRemediation
오브젝트입니다.
$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
출력 예
NAME STATE rhcos4-e8-worker-audit-rules-dac-modification-chmod NotApplied rhcos4-e8-worker-audit-rules-dac-modification-chown NotApplied rhcos4-e8-worker-audit-rules-execution-chcon NotApplied rhcos4-e8-worker-audit-rules-execution-restorecon NotApplied rhcos4-e8-worker-audit-rules-execution-semanage NotApplied rhcos4-e8-worker-audit-rules-execution-setfiles NotApplied
이러한 CR이 생성되면 집계기 Pod가 종료되고 검사가 완료 단계로 전환됩니다.
5.12.1.4.5. 완료 단계
최종 검사 단계에서는 필요한 경우 검사 리소스가 정리되고 ResultServer
배포가 축소되거나(검사가 1회인 경우) 삭제됩니다(검사가 계속되는 경우). 삭제하는 경우 다음 검사 인스턴스에서 배포를 다시 생성합니다.
또한 주석을 달아 완료 단계에서 검사 재실행을 트리거할 수도 있습니다.
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
autoApplyRemediations: true
를 사용하여 수정을 자동 적용하도록 설정하지 않으면 검사가 완료 단계에 도달한 후 자체적으로 수행되는 작업이 없습니다. OpenShift Container Platform 관리자가 수정 사항을 검토하고 필요에 따라 적용합니다. 수정을 자동 적용하도록 설정하면 완료 단계에서 ComplianceSuite
컨트롤러에 설정이 전달되고, 이 컨트롤러에서 검사가 매핑되는 머신 구성 풀을 일시 중지한 후 모든 수정을 한 번에 적용합니다. 수정은 ComplianceRemediation
컨트롤러에서 대신 적용합니다.
5.12.1.5. ComplianceRemediation 컨트롤러 라이프사이클 및 디버깅
예제 검사에서 몇 가지 결과가 보고되었습니다. apply
특성을 true
로 전환하여 수정 중 하나를 활성화할 수 있습니다.
$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge
ComplianceRemediation
컨트롤러(logger=remediationctrl
)는 수정된 오브젝트를 조정합니다. 조정으로 인해 조정된 수정 오브젝트의 상태가 변경될 뿐만 아니라 적용된 모든 수정이 포함되는 렌더링된 모음별 MachineConfig
오브젝트도 변경됩니다.
MachineConfig
오브젝트는 항상 75-
로 시작하며 검사 및 모음 이름을 따서 이름이 지정됩니다.
$ oc get mc | grep 75-
출력 예
75-rhcos4-e8-worker-my-companys-compliance-requirements 3.2.0 2m46s
현재 mc
가 구성되어 있는 수정이 머신 구성의 주석에 나열됩니다.
$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements
출력 예
Name: 75-rhcos4-e8-worker-my-companys-compliance-requirements Labels: machineconfiguration.openshift.io/role=worker Annotations: remediation/rhcos4-e8-worker-audit-rules-dac-modification-chmod:
ComplianceRemediation
컨트롤러 알고리즘은 다음과 같이 작동합니다.
- 현재 적용된 모든 수정은 초기 수정 세트로 해석됩니다.
- 조정된 수정을 적용해야 하는 경우 이 세트에 추가됩니다.
-
MachineConfig
오브젝트는 해당 세트에서 렌더링되고 세트의 수정 이름으로 주석이 달립니다. 세트가 비어 있는 경우(마지막 수정이 적용되지 않음) 렌더링된MachineConfig
오브젝트가 제거됩니다. - 렌더링된 머신 구성이 클러스터에 이미 적용된 구성과 다른 경우에만 적용된 MC가 업데이트되거나 생성 또는 삭제됩니다.
-
MachineConfig
오브젝트를 생성하거나 수정하면machineconfiguration.openshift.io/role
레이블과 일치하는 노드의 재부팅이 트리거됩니다. 자세한 내용은 Machine Config Operator 설명서를 참조하십시오.
필요한 경우 렌더링된 머신 구성을 업데이트하고 조정된 수정 오브젝트 상태를 업데이트하면 수정 루프가 종료됩니다. 예제의 경우 수정을 적용하면 재부팅이 트리거됩니다. 재부팅 후 검사에 주석을 달아 다시 실행합니다.
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
검사가 실행되고 완료됩니다. 전달할 수정을 확인합니다.
$ oc -n openshift-compliance \ get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod
출력 예
NAME STATUS SEVERITY rhcos4-e8-worker-audit-rules-dac-modification-chmod PASS medium
5.12.1.6. 유용한 레이블
Compliance Operator에서 생성하는 각 Pod는 특별히 해당 Pod가 속하는 검사와 수행하는 작업을 사용하여 레이블이 지정됩니다. 검사 식별자는 compliance.openshift.io/scan-name
으로 레이블이 지정됩니다. 워크로드 식별자는 workload
로 레이블이 지정됩니다.
Compliance Operator는 다음 워크로드를 예약합니다.
- scanner: 규정 준수 스캔을 수행합니다.
- resultserver: 규정 준수 스캔의 원시 결과를 저장합니다.
- aggregator: 결과를 집계하고, 불일치를 감지하고, 결과 오브젝트를 출력합니다(검사 결과 및 수정).
- suitererunner: 은 다시 실행할 슈트에 태그를 지정합니다(일정이 설정된 경우).
- profileparser: 데이터 스트림을 구문 분석하고 적절한 프로필, 규칙 및 변수를 생성합니다.
특정 워크로드에 디버깅 및 로그가 필요한 경우 다음을 실행합니다.
$ oc logs -l workload=<workload_name> -c <container_name>
5.12.2. Compliance Operator 리소스 제한 증가
경우에 따라 Compliance Operator에 기본 제한 허용보다 많은 메모리가 필요할 수 있습니다. 이 문제를 완화하는 가장 좋은 방법은 사용자 정의 리소스 제한을 설정하는 것입니다.
스캐너 Pod의 기본 메모리 및 CPU 제한을 늘리려면 'ScanSetting' 사용자 정의 리소스를 참조하십시오.
프로세스
Operator의 메모리 제한을 500 Mi로 늘리려면
co-memlimit-patch.yaml
이라는 패치 파일을 생성합니다.spec: config: resources: limits: memory: 500Mi
패치 파일을 적용합니다.
$ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge
5.12.3. Operator 리소스 제약 조건 구성
resources
필드는 OLM(Operator Lifecycle Manager)에서 생성한 Pod의 모든 컨테이너에 대한 리소스 제약 조건을 정의합니다.
이 프로세스에 적용된 리소스 제약 조건은 기존 리소스 제약 조건을 덮어씁니다.
프로세스
Subscription
오브젝트를 편집하여 0.25 cpu 및 64 Mi의 메모리 요청과 각 컨테이너에서 메모리 제한 0.5 cpu 및 128 Mi를 삽입합니다.kind: Subscription metadata: name: custom-operator spec: package: etcd channel: alpha config: resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
5.12.4. 지원 요청
이 문서에 설명된 절차 또는 일반적으로 OpenShift Container Platform에 문제가 발생하는 경우 Red Hat 고객 포털에 액세스하십시오. 고객 포털에서 다음을 수행할 수 있습니다.
- Red Hat 제품과 관련된 기사 및 솔루션에 대한 Red Hat 지식베이스를 검색하거나 살펴볼 수 있습니다.
- Red Hat 지원에 대한 지원 케이스 제출할 수 있습니다.
- 다른 제품 설명서에 액세스 가능합니다.
클러스터 문제를 식별하려면 OpenShift Cluster Manager 에서 Insights를 사용할 수 있습니다. Insights는 문제에 대한 세부 정보 및 문제 해결 방법에 대한 정보를 제공합니다.
이 문서를 개선하기 위한 제안이 있거나 오류를 발견한 경우 가장 관련 있는 문서 구성 요소에 대한 Jira 문제를 제출하십시오. 섹션 이름 및 OpenShift Container Platform 버전과 같은 구체적인 정보를 제공합니다.