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-enable-fips-mode 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-enable-fips-mode 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 ocp4-moderate-fips-mode-enabled-on-all-nodes FAIL high
手動で修復する必要のある障害のあるチェックをすべてリスト表示します。
$ oc get -n openshift-compliance compliancecheckresults \ -l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'
手動による修復の手順は、通常 ComplianceCheckResult
オブジェクトの description
属性に保存されます。
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.23.3+d99c04f ip-10-0-158-32.us-east-2.compute.internal Ready worker 5h17m v1.23.3+d99c04f ip-10-0-166-81.us-east-2.compute.internal Ready worker 5h17m v1.23.3+d99c04f ip-10-0-171-170.us-east-2.compute.internal Ready master 5h21m v1.23.3+d99c04f ip-10-0-197-35.us-east-2.compute.internal Ready master 5h22m v1.23.3+d99c04f
ノードにラベルを追加します。
$ 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
カスタム
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) に追加するラベル名を定義します。
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-scan
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 * * *'
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 - 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
サブプールに適用できます。
手順
ラベルをサブプール
MachineConfigPool
CR に追加します。$ 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
注記修復によって
evictionHard
kubelet 設定が呼び出される場合は、すべての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=merge
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
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=