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) を作成します。デフォルトで、Compliance Operator はクラスターに設定されるストレージクラスについて何らかの仮定をすることができないため、PV はアクセスモード ReadWriteOnce を使用します。さらに、ReadWriteOnce アクセスモードはほとんどのクラスターで利用できます。スキャン結果を取得する必要がある場合は、ボリュームもバインドするヘルパー Pod を使用して実行できます。ReadWriteOnce アクセスモードを使用するボリュームは、一度に 1 つの Pod のみがマウントできるため、必ずヘルパー Pod を削除してください。そうでない場合は、Compliance Operator は後続のスキャンのためにボリュームを再利用できません。

   2

   Compliance Operator は、後続の 3 つのスキャンの結果をボリュームに保持し、古いスキャンはローテーションされます。

   3

   Compliance Operator はスキャンの結果用に 1 GB のストレージを割り当てます。

   4

   scansetting.rawResultStorage.storageClassName フィールドは、raw の結果を保存するための 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 オブジェクトにバインドし、cis および cis-node プロファイルを使用してクラスターをスキャンする ScanSettingBinding オブジェクトを作成します。以下に例を示します。

   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. 次のコマンドを実行して、スキャン対象のホストされたクラスターの name と namespace を取得します。

   $ 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 を作成し、スキャンするホストされたクラスターの名前と namespace を定義します。

   例: 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

   value は、前の手順の出力の NAME です。

   3

   value は、直前のステップの出力の NAMESPACE です。

3. TailoredProfile を作成します。

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

手順

1. Red Hat Enterprise Linux CoreOS (RHCOS) 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 に追加するルールを選択します。この例では、2 つのルールを無効にし、1 つの値を変更することにより、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 スペック変数の属性

      属性	説明
      extends	この TailoredProfile がビルドされる Profile オブジェクトの名前。
      title	人間が判読できる TailoredProfile のタイトル。
      disableRules	名前および理論的根拠のペアのリスト。名前ごとに、無効にするルールオブジェクトの名前を参照します。理論的根拠の値は、人間が判読できるテキストで、ルールが無効になっている理由を記述します。
      manualRules	名前および理論的根拠のペアのリスト。手動ルールを追加すると、チェック結果のステータスは常に manual になり、修復は生成されません。この属性は自動であり、手動ルールとして設定されている場合、デフォルトでは値がありません。
      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 namespace で作成されます。

      出力例

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

4. ScanSettingBinding オブジェクトを定義して、新しい調整されたプロファイル nist-moderate-modified をデフォルトの ScanSetting オブジェクトにバインドします。

   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. 結果のいずれかの名前と namespace を使用して、未加工データの場所を確認します。

   $ 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 に設定されている場合、ボリュームは一度に 1 つの 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.26.0
   ip-10-0-158-32.us-east-2.compute.internal  Ready   worker 5h17m  v1.26.0
   ip-10-0-166-81.us-east-2.compute.internal  Ready   worker 5h17m  v1.26.0
   ip-10-0-171-170.us-east-2.compute.internal Ready   master 5h21m  v1.26.0
   ip-10-0-197-35.us-east-2.compute.internal  Ready   master 5h22m  v1.26.0

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) に追加するラベル名を定義します。

4. MCP が正常に作成されたことを確認します。

   $ oc get mcp -w

手順

1. ScanSettingBinding CR に保存される ScanSetting オブジェクトに example ロールを追加します。

   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 を 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

   コンプライアンスオペレータースキャナー 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 のメモリー制限を 500 Mi に増やすには、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 にすることができます。複数のオブジェクトを指定できます。
   • オブジェクト名は、.metadata.name などの Kubernetes リソースの名前です。

   • --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