5.5. Compliance Operator のスキャン
ScanSetting および
ScanSettingBinding
API は、Compliance Operator でコンプライアンススキャンを実行するために使用することが推奨されます。これらの API オブジェクトの詳細については、以下を実行します。
$ oc explain scansettings
または
$ oc explain scansettingbindings
5.5.1. コンプライアンススキャンの実行
Center for Internet Security (CIS) プロファイルを使用してスキャンを実行できます。便宜上、Compliance Operator は起動時に適切なデフォルト値を持つ ScanSetting
オブジェクトを作成します。この ScanSetting
オブジェクトの名前は default
です。
オールインワンのコントロールプレーンノードとワーカーノードの場合、コンプライアンススキャンはワーカーノードとコントロールプレーンノードで 2 回実行されます。コンプライアンススキャンは、一貫性のないスキャン結果を生成する可能性があります。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) を作成します。デフォルトで、Compliance Operator はクラスターに設定されるストレージクラスについて何らかの仮定をすることができないため、PV はアクセスモード
ReadWriteOnce
を使用します。さらに、ReadWriteOnce
アクセスモードはほとんどのクラスターで利用できます。スキャン結果を取得する必要がある場合は、ボリュームもバインドするヘルパー Pod を使用して実行できます。ReadWriteOnce
アクセスモードを使用するボリュームは、一度に 1 つの Pod のみがマウントできるため、必ずヘルパー Pod を削除してください。そうでない場合は、Compliance Operator は後続のスキャンのためにボリュームを再利用できません。 - 2
- Compliance Operator は、後続の 3 つのスキャンの結果をボリュームに保持し、古いスキャンはローテーションされます。
- 3
- Compliance Operator はスキャンの結果用に 1 GB のストレージを割り当てます。
- 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 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>
デフォルトの
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
設定に基づいて調整されます。Compliance Operator はComplianceSuite
オブジェクトおよび関連付けられるComplianceScan
オブジェクトを作成します。以下を実行してコンプライアンススキャンの進捗を確認します。
$ oc get compliancescan -w -n openshift-compliance
スキャンはスキャンフェーズに進み、完了すると最終的に
DONE
フェーズに移行します。ほとんどの場合、スキャンの結果はNON-COMPLIANT
になります。スキャン結果を確認し、クラスターがコンプライアンスに基づくように修復の適用を開始することができます。詳細は、Compliance Operator 修復の管理 を参照してください。
5.5.2. ワーカーノードでの結果サーバー Pod のスケジューリング
結果サーバー Pod は、生の Asset Reporting Format (ARF) スキャン結果を格納する永続ボリューム (PV) をマウントします。nodeSelector
属性および tolerations
属性を使用すると、結果サーバー 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
カスタムリソースでは、scan limits 属性を使用して、スキャナー Pod のデフォルトの CPU およびメモリー制限をオーバーライドできるようになりました。Compliance Operator は、スキャナーコンテナーに 500Mi メモリー、100m CPU のデフォルトを使用し、api-resource-collector
コンテナーに 100m CPU の 200Mi メモリーを使用します。Operator のメモリー制限を設定するには、OLM または Operator デプロイメント自体を介してインストールされている場合は Subscription
オブジェクトを変更します。
Compliance Operator のデフォルトの CPU およびメモリーの制限を増やすには、Compliance Operator リソース制限の増加 を参照してください。
デフォルトの制限が十分ではなく、Operator またはスキャナー Pod が Out Of Memory (OOM) プロセスによって終了した場合は、Compliance Operator または Scanner Pod のメモリー制限を増やす必要があります。
5.5.4. リソース要求および制限の適用
kubelet が Pod の一部としてコンテナーを起動すると、kubelet はそのコンテナーの要求および制限をメモリーおよび CPU の要求および制限をコンテナーランタイムに渡します。Linux では、コンテナーランタイムは、定義した制限を適用して有効にするカーネル cgroup を設定します。
CPU 制限は、コンテナーが使用できる CPU 時間を定義します。各スケジューリング期間中、Linux カーネルはこの制限を超えるかどうかを確認します。その場合、カーネルは、cgroup の実行を再開できるようにするまで待機します。
複数の異なるコンテナー (cgroup) を競合するシステムで実行する場合、CPU 要求が大きいワークロードには、要求が小さいワークロードよりも多くの CPU 時間が割り当てられます。メモリー要求は Pod のスケジューリング時に使用されます。cgroups v2 を使用するノードでは、コンテナーランタイムがメモリーリクエストをヒントとして使用して、memory.min
および memory.low の
値を設定する場合があります。
コンテナーがこの制限を超えるメモリーを割り当てようとすると、Linux カーネルのメモリー不足サブシステムがアクティブになり、メモリーを割り当てようとしたコンテナー内のプロセスの 1 つを停止して介入します。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"