5.14. oc-compliance 플러그인 사용

프로세스

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
     ocp4-cis          9m54s
     ocp4-cis-node     9m54s
     ocp4-e8           9m54s
     ocp4-moderate     9m54s
     ocp4-ncp          9m54s
     rhcos4-e8         9m54s
     rhcos4-moderate   9m54s
     rhcos4-ncp        9m54s
     rhcos4-ospp       9m54s
     rhcos4-stig       9m54s

     $ 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