5.4. コンプライアンス Operator のスキャン
ScanSetting および ScanSettingBinding API は、コンプライアンス Operator でコンプライアンススキャンを実行するために使用することが推奨されます。これらの API オブジェクトの詳細については、以下を実行します。
$ oc explain scansettings
または
$ oc explain scansettingbindings
5.4.1. コンプライアンススキャンの実行 リンクのコピーリンクがクリップボードにコピーされました!
Center for Internet Security (CIS) プロファイルを使用してスキャンを実行できます。便宜上、コンプライアンス Operator は起動時に適切なデフォルト値を持つ ScanSetting オブジェクトを作成します。この ScanSetting オブジェクトの名前は default です。
オールインワンのコントロールプレーンノードとワーカーノードの場合、コンプライアンススキャンはワーカーノードとコントロールプレーンノードで 2 回実行されます。コンプライアンススキャンは、一貫性のないスキャン結果を生成する可能性があります。ScanSetting オブジェクトで単一のロールのみを定義することにより、一貫性のない結果を回避できます。
手順
以下を実行して
ScanSettingオブジェクトを検査します。$ oc describe scansettings default -n openshift-compliance出力例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: pvAccessModes: - ReadWriteOnce1 rotation: 32 size: 1Gi3 roles: - worker4 - master5 scanTolerations:6 default: - operator: Exists schedule: 0 1 * * *7 - 1
- コンプライアンス Operator は、スキャンの結果が含まれる永続ボリューム (PV) を作成します。デフォルトで、コンプライアンス Operator はクラスターに設定されるストレージクラスについて何らかの仮定をすることができないため、PV はアクセスモード
ReadWriteOnceを使用します。さらに、ReadWriteOnceアクセスモードはほとんどのクラスターで利用できます。スキャン結果を取得する必要がある場合は、ボリュームもバインドするヘルパー Pod を使用して実行できます。ReadWriteOnceアクセスモードを使用するボリュームは、一度に 1 つの Pod のみがマウントできるため、必ずヘルパー Pod を削除してください。そうでない場合は、コンプライアンス Operator は後続のスキャンのためにボリュームを再利用できません。 - 2
- コンプライアンス Operator は、後続の 3 つのスキャンの結果をボリュームに保持し、古いスキャンはローテーションされます。
- 3
- コンプライアンス Operator はスキャンの結果用に 1 GB のストレージを割り当てます。
- 4 5
- スキャン設定がクラスターノードをスキャンするプロファイルを使用する場合は、これらのノードロールをスキャンします。
- 6
- デフォルトのスキャン設定オブジェクトはすべてのノードもスキャンします。
- 7
- デフォルトのスキャン設定オブジェクトは、毎日 01:00 にスキャンを実行します。
デフォルトのスキャン設定の代わりに、以下の設定を含む
default-auto-applyを使用できます。apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default-auto-apply namespace: openshift-compliance autoUpdateRemediations: true1 autoApplyRemediations: true2 rawResultStorage: pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi schedule: 0 1 * * * roles: - worker - master scanTolerations: default: - operator: Existsデフォルトの
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以下を実行して
ScanSettingBindingオブジェクトを作成します。$ oc create -f <file-name>.yaml -n openshift-complianceプロセスのこの時点で、
ScanSettingBindingオブジェクトは調整され、BindingおよびBound設定に基づいて調整されます。コンプライアンス Operator はComplianceSuiteオブジェクトおよび関連付けられるComplianceScanオブジェクトを作成します。以下を実行してコンプライアンススキャンの進捗を確認します。
$ oc get compliancescan -w -n openshift-complianceスキャンはスキャンフェーズに進み、完了すると最終的に
DONEフェーズに移行します。ほとんどの場合、スキャンの結果はNON-COMPLIANTになります。スキャン結果を確認し、クラスターがコンプライアンスに基づくように修復の適用を開始することができます。詳細は、コンプライアンス Operator 修復の管理 について参照してください。
5.4.2. ワーカーノードでの結果サーバー Pod のスケジューリング リンクのコピーリンクがクリップボードにコピーされました!
結果サーバー Pod は、生の Asset Reporting Format (ARF) スキャン結果を格納する永続ボリューム (PV) をマウントします。nodeSelector 属性および tolerations 属性を使用すると、結果サーバー Pod の場所を設定できます。
これは、コントロールプレーンノードが永続ボリュームをマウントすることを許可されていない環境で役立ちます。
手順
コンプライアンス Operator 用の
ScanSettingカスタムリソース (CR) を作成します。ScanSettingCR を定義し、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: Exists2 roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * *ScanSettingCR を作成するには、次のコマンドを実行します。$ 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