5.10. Compliance Operator の結果と修復の管理
それぞれの ComplianceCheckResult は、1 つのコンプライアンスルールチェックの結果を表します。ルールを自動的に修復できる場合、ComplianceCheckResult によって所有される、同じ名前を持つ ComplianceRemediation オブジェクトが作成されます。修復が要求されない限り、修復は自動的に適用されません。これにより、OpenShift Container Platform の管理者は修復内容を確認し、検証後にのみ修復を適用することができます。
5.10.1. コンプライアンスチェック結果のフィルター
デフォルトで、ComplianceCheckResult オブジェクトには、チェックのクエリーおよび結果の生成後に次のステップを決定することを可能にする便利なラベルが複数付けられます。
特定のスイートに属するチェックを一覧表示します。
$ oc get -n openshift-compliance compliancecheckresults \ -l compliance.openshift.io/suite=workers-compliancesuite
特定のスキャンに属するチェックを一覧表示します。
$ oc get -n openshift-compliance compliancecheckresults \ -l compliance.openshift.io/scan=workers-scan
すべての ComplianceCheckResult オブジェクトが ComplianceRemediation オブジェクトを作成する訳ではありません。自動的に修復できる ComplianceCheckResult オブジェクトのみになります。ComplianceCheckResult オブジェクトには、compliance.openshift.io/automated-remediation ラベルでラベル付けされる場合に関連する修復が含まれます。修復の名前はチェックの名前と同じです。
自動的に修復できる障害のあるチェックをすべて一覧表示します。
$ oc get -n openshift-compliance compliancecheckresults \ -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'
失敗したすべてのチェックを重大度順に一覧表示します。
$ oc get compliancecheckresults -n openshift-compliance \ -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/check-severity=high'
出力例
NAME STATUS SEVERITY nist-moderate-modified-master-configure-crypto-policy FAIL high nist-moderate-modified-master-coreos-pti-kernel-argument FAIL high nist-moderate-modified-master-disable-ctrlaltdel-burstaction FAIL high nist-moderate-modified-master-disable-ctrlaltdel-reboot FAIL high nist-moderate-modified-master-no-empty-passwords FAIL high nist-moderate-modified-master-selinux-state FAIL high nist-moderate-modified-worker-configure-crypto-policy FAIL high nist-moderate-modified-worker-coreos-pti-kernel-argument FAIL high nist-moderate-modified-worker-disable-ctrlaltdel-burstaction FAIL high nist-moderate-modified-worker-disable-ctrlaltdel-reboot FAIL high nist-moderate-modified-worker-no-empty-passwords FAIL high nist-moderate-modified-worker-selinux-state FAIL high ocp4-moderate-configure-network-policies-namespaces FAIL high
手動で修復する必要のある障害のあるチェックをすべて一覧表示します。
$ oc get -n openshift-compliance compliancecheckresults \ -l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'
手動による修復の手順は、通常 ComplianceCheckResult オブジェクトの description 属性に保存されます。
表5.3 ComplianceCheckResult Status
| ComplianceCheckResult Status | 説明 |
|---|---|
| PASS | コンプライアンスチェックが完了し、パスしました。 |
| FAIL | コンプライアンスチェックが完了するまで実行され、失敗しました。 |
| INFO | コンプライアンスチェックが完了するまで実行され、エラーと見なされるほど深刻ではないものが見つかりました。 |
| MANUAL | コンプライアンスチェックには、成功または失敗を自動的に評価する方法がないため、手動でチェックする必要があります。 |
| INCONSISTENT | コンプライアンスチェックは、さまざまなソース (通常はクラスターノード) からのさまざまな結果を報告します。 |
| ERROR | コンプライアンスチェックは実行されましたが、正しく完了できませんでした。 |
| NOT-APPLICABLE | 該当しない、または選択されていないため、コンプライアンスチェックは実行されませんでした。 |
5.10.2. 修復の確認
ComplianceRemediation オブジェクト、および修復を所有する ComplianceCheckResult オブジェクトの両方を確認します。ComplianceCheckResult オブジェクトには、チェック内容やサーバーの強化措置などの人間が判読できる記述、および重大度や関連するセキュリティーコントロールなどの他の metadata が含まれます。ComplianceRemediation オブジェクトは、ComplianceCheckResult に説明されている問題を修正する方法を表します。最初のスキャン後、MissingDependencies 状態の修復を確認します。
以下は、sysctl-net-ipv4-conf-all-accept-redirects というチェックおよび修復の例です。この例では、spec および status のみを表示し、metadata は省略するように編集されています。
spec:
apply: false
current:
object:
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
config:
ignition:
version: 3.2.0
storage:
files:
- path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
mode: 0644
contents:
source: data:,net.ipv4.conf.all.accept_redirects%3D0
outdated: {}
status:
applicationState: NotApplied
修復ペイロードは spec.current 属性に保存されます。ペイロードには Kubernetes オブジェクトを使用することができますが、この修復はノードスキャンによって生成されたため、上記の例の修復ペイロードは MachineConfig オブジェクトになります。Platform スキャンでは、修復ペイロードは多くの場合 (ConfigMap や Secret オブジェクトなど) 異なる種類のオブジェクトになりますが、通常は修復を適用については管理者が判断します。そうでない場合には、Compliance Operator には汎用の Kubernetes オブジェクトを操作するために非常に幅広いパーミッションのセットが必要になるためです。Platform チェックの修復例は、後ほど提供されます。
修復が適用される際に修復内容を正確に確認できるようにするために、MachineConfig オブジェクトの内容は設定の Ignition オブジェクトを使用します。形式についての詳細は、Ignition 仕様 を参照してください。この例では、spec.config.storage.files[0].path 属性は、この修復によって作成されるファイル (/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf) を指定し、spec.config.storage.files[0].contents.source 属性はそのファイルの内容を指定します。
ファイルの内容は URL でエンコードされます。
以下の Python スクリプトを使用して、コンテンツを表示します。
$ echo "net.ipv4.conf.all.accept_redirects%3D0" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"出力例
net.ipv4.conf.all.accept_redirects=0
5.10.3. カスタマイズされたマシン設定プールを使用するときに修復を適用する
カスタム MachineConfigPool を作成するときは、MachineConfigPool にラベルを追加して、KubeletConfig に存在する machineConfigPoolSelector がそのラベルを MachineConfigPool と一致させることができるようにします。
Compliance Operator が修復の適用を終了した後に、MachineConfigPool オブジェクトが予期せず一時停止を解除できない可能性があるため、KubeletConfig ファイルでは、protectKernelDefaults:false を設定しないでください。
手順
ノードを一覧表示します。
$ 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
ノードにラベルを追加します。
$ 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
カスタム
MachineConfigPoolCR を作成します。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) に追加するラベル名を定義します。
MCP が正常に作成されたことを確認します。
$ oc get mcp -w
5.10.4. デフォルトの設定値をもとにした KubeletConfig ルールの評価
OpenShift Container Platform インフラストラクチャーには、実行時に不完全な設定ファイルが含まれる場合があり、ノードは、設定オプションが欠落している場合には、設定値がデフォルトであることを想定します。一部の設定オプションは、コマンドライン引数として渡すことができます。その結果、Compliance Operator はノード上の設定ファイルが完全かどうかを確認できません。これは、ルールチェックで使用されるオプションが欠落している可能性があるためです。
デフォルトの設定値がチェックに合格するといったフォールスネガティブの結果に陥らないように、Compliance Operator はノード/プロキシー API を使用してノードのプール内にあるノードごとに設定をフェッチし、次にノードプール内のノード全体で整合性が取れた設定オプションすべてをファイルに保存することで、このファイルが対象ノードプール内の全ノードの設定を表します。これにより、スキャン結果の精度が向上します。
デフォルトの マスター および ワーカー ノードプール設定でこの機能を使用するために、追加の設定変更は必要ありません。
5.10.5. カスタムノードプールのスキャン
Compliance Operator は、各ノードプール設定のコピーを維持しません。Compliance Operator は、単一ノードプール内のすべてのノードについて一貫性のある設定オプションを設定ファイルの 1 つのコピーに集約します。次に、Compliance Operator は、特定のノードプールの設定ファイルを使用して、そのプール内のノードに対してルールを評価します。
クラスターがデフォルトの ワーカー ノードおよび マスター ノードプール外のカスタムノードプールを使用する場合、Compliance Operator がそのノードプールの設定ファイルを集約できるように追加の変数を指定する必要があります。
手順
master、worker、およびカスタムのexampleノードプールを含むサンプルクラスター内のすべてのプールに対して設定をチェックするには、TailoredProfileオブジェクトのocp-var-role-masterおよびopc-var-role-workerフィールドの値をexampleに設定します。apiVersion: compliance.openshift.io/v1alpha1 kind: TailoredProfile metadata: name: cis-example-tp spec: extends: ocp4-cis title: My modified NIST profile to scan example nodes setValues: - name: ocp4-var-role-master value: example rationale: test for example nodes - name: ocp4-var-role-worker value: example rationale: test for example nodes description: cis-example-scanScanSettingBindingCR に保存される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 * * *'
ScanSettingBindingCR を使用するスキャンを作成します。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 - apiGroup: compliance.openshift.io/v1alpha1 kind: TailoredProfile name: cis-example-tp settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: default
Compliance Operator は Node/Proxy API オブジェクトを使用してランタイム KubeletConfig をチェックし、ocp-var-role-master および ocp-var-role-worker などの変数を使用してチェックを実行するノードを判別します。ComplianceCheckResult では、KubeletConfig ルールは ocp4-cis-kubelet-* と表示されます。スキャンは、選択したすべてのノードがこのチェックに合格した場合にのみ、合格します。
検証
Platform KubeletConfig ルールは、
Node/Proxyオブジェクトを介してチェックされます。これらのルールは、以下のコマンドを実行して検索できます。$ oc get rules -o json | jq '.items[] | select(.checkType == "Platform") | select(.metadata.name | contains("ocp4-kubelet-")) | .metadata.name'
5.10.6. KubeletConfig サブプールの修復
KubeletConfig 修復ラベルは MachineConfigPool サブプールに適用できます。
手順
ラベルをサブプール
MachineConfigPoolCR に追加します。$ oc label mcp <sub-pool-name> pools.operator.machineconfiguration.openshift.io/<sub-pool-name>=
5.10.7. 修復の適用
ブール値の属性 spec.apply は、Compliance Operator で修復を適用するかどうかを制御します。属性を true に設定すると、修復を適用することができます。
$ oc -n openshift-compliance \
patch complianceremediations/<scan-name>-sysctl-net-ipv4-conf-all-accept-redirects \
--patch '{"spec":{"apply":true}}' --type=merge
Compliance Operator が適用された修復を処理した後に、status.ApplicationState 属性は Applied に、または正しくない場合には Error に切り替わります。マシン設定の修復が適用されると、その修復と他のすべての適用済みの修復が 75-$scan-name-$suite-name という名前の MachineConfig オブジェクトにレンダリングされます。MachineConfig オブジェクトはその後 Machine Config Operator によってレンダリングされ、最終的に各ノードで実行されるマシン制御デーモンのインスタンスによってマシン設定プールのすべてのノードに適用されます。
Machine Config Operator が新規 MachineConfig オブジェクトをプール内のノードに適用すると、そのプールに属するすべてのノードが再起動されることに注意してください。これは、それぞれが複合の 75-$scan-name-$suite-name MachineConfig オブジェクトを再度レンダリングする、複数の修復を適用する際に不都合が生じる可能性があります。修復をすぐに適用しないようにするには、MachineConfigPool オブジェクトの .spec.paused 属性を true に設定してマシン設定プールを一時停止できます。
Compliance Operator は修復を自動的に適用できます。ScanSetting の最上位のオブジェクトに autoApplyRemediations: true を設定します。
修復の自動敵に適用するかどうかについては、慎重に考慮する必要があります。
5.10.8. プラットフォームチェックの手動による修復
通常、プラットフォームスキャンをチェックする場合、以下の 2 つの理由のために管理者が手動で修復する必要があります。
- 設定する必要のある値は、常に自動的に判別できる訳ではありません。チェックのいずれかで許可されたレジストリーの一覧が指定されることが必要になりますが、スキャナー側が組織が許可する必要のあるレジストリーを認識する方法はありません。
-
異なるチェックで異なる API オブジェクトが変更されるため、クラスター内のオブジェクトを変更するために自動化された修復で
rootまたはスーパーユーザーアクセスを所有することが要求されますが、これは推奨されていません。
手順
以下の例では、
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スキャンを再実行します。
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
5.10.9. 修復の更新
新しいバージョンのコンプライアンスコンテンツが使用されると、以前のバージョンとは異なる新しいバージョンの修復が提供される可能性があります。Compliance Operator は、適用される修復の以前のバージョンを保持します。OpenShift Container Platform の管理者は、確認し、適用する新規バージョンについても通知されます。以前に適用されたものの、更新された ComplianceRemediation オブジェクトはそのステータスを Outdated に変更します。古いオブジェクトには簡単に検索できるようにラベルが付けられます。
以前に適用された修復内容は ComplianceRemediation オブジェクトの spec.outdated 属性に保存され、新規に更新された内容は spec.current 属性に保存されます。コンテンツを新しいバージョンに更新した後に、管理者は修復を確認する必要があります。spec.outdated 属性が存在する限り、これは結果として作成される MachineConfig オブジェクトをレンダリングするために使用されます。spec.outdated 属性が削除された後に、Compliance Operator は結果として生成される MachineConfig オブジェクトを再度レンダリングし、これにより Operator は設定をノードにプッシュします。
手順
古い修復について検索します。
$ 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属性を削除します。修復の新しいバージョンを適用します。
$ oc -n openshift-compliance patch complianceremediations workers-scan-no-empty-passwords \ --type json -p '[{"op":"remove", "path":/spec/outdated}]'修復の状態は、
OutdatedからAppliedに切り替わります。$ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords
出力例
NAME STATE workers-scan-no-empty-passwords Applied
- ノードは新規の修復バージョンを適用し、再起動します。
5.10.10. 修復の適用解除
以前に適用された修復を適用解除することが必要になる場合があります。
手順
applyフラグをfalseに設定します。$ oc -n openshift-compliance \ patch complianceremediations/rhcos4-moderate-worker-sysctl-net-ipv4-conf-all-accept-redirects \ --patch '{"spec":{"apply":false}}' --type=merge修復ステータスは
NotAppliedに変更され、複合のMachineConfigオブジェクトは修復を含まないように再度レンダリングされます。重要修復を含む影響を受けるすべてのノードが再起動されます。
5.10.11. KubeletConfig 修復の削除
KubeletConfig の修正は、ノードレベルのプロファイルに含まれています。KubeletConfig 修復を削除するには、KubeletConfig オブジェクトから手動で削除する必要があります。この例は、one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available 修正のコンプライアンスチェックを削除する方法を示しています。
手順
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注記修復によって
evictionHardkubelet 設定が呼び出される場合は、すべてのevictionHardパラメーター (memory.available、nodefs.available、nodefs.inodesFree、imagefs.available、およびimagefs.inodesFree) を指定する必要があります。すべてのパラメーターを指定しないと、指定したパラメーターのみが適用され、修正が正しく機能しません。修復を削除します。
修復オブジェクトの
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=mergescan-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
KubeletConfigオブジェクトから修復imagefs.available: 10%を手動で削除します。$ oc edit -n openshift-compliance KubeletConfig compliance-operator-kubelet-master
重要修復を含む影響を受けるすべてのノードが再起動されます。
また、修正を自動適用する調整済みプロファイルのスケジュールされたスキャンからルールを除外する必要があります。除外しない場合、修正は次のスケジュールされたスキャン中に再適用されます。
5.10.12. 一貫性のない ComplianceScan
ScanSetting オブジェクトは、ScanSetting または ScanSettingBinding オブジェクトから生成されるコンプライアンススキャンがスキャンするノードロールを一覧表示します。通常、各ノードのロールはマシン設定プールにマップされます。
マシン設定プールのすべてのマシンが同一であり、プールのノードからのすべてのスキャン結果が同一であることが予想されます。
一部の結果が他とは異なる場合、Compliance Operator は一部のノードが INCONSISTENT として報告される ComplianceCheckResult オブジェクトにフラグを付けます。すべての ComplianceCheckResult オブジェクトには、compliance.openshift.io/inconsistent-check のラベルも付けられます。
プール内のマシン数は非常に大きくなる可能性があるため、Compliance Operator は最も一般的な状態を検索し、一般的な状態とは異なるノードを一覧表示しようとします。最も一般的な状態は compliance.openshift.io/most-common-status アノテーションに保存され、アノテーション compliance.openshift.io/inconsistent-source には、最も一般的なステータスとは異なるチェックステータスの hostname:status のペアが含まれます。共通状態が見つからない場合、すべての hostname:status ペアが compliance.openshift.io/inconsistent-source アノテーションに一覧表示されます。
可能な場合は、修復が依然として作成され、クラスターが準拠したステータスに収束できるようにします。ただし、これが常に実行可能な訳ではなく、ノード間の差異の修正は手作業で行う必要があります。スキャンに compliance.openshift.io/rescan= オプションのアノテーションを付けて一貫性のある結果を取得するために、コンプライアンススキャンを再実行する必要があります。
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=