5.9. コンプライアンス Operator の結果と修復の管理
それぞれの ComplianceCheckResult
は、1 つのコンプライアンスルールチェックの結果を表します。ルールを自動的に修復できる場合、ComplianceCheckResult
によって所有される、同じ名前を持つ ComplianceRemediation
オブジェクトが作成されます。修復が要求されない限り、修復は自動的に適用されません。これにより、OpenShift Container Platform の管理者は修復内容を確認し、検証後にのみ修復を適用することができます。
5.9.1. コンプライアンスチェック結果のフィルター
デフォルトで、ComplianceCheckResult
オブジェクトには、チェックのクエリーおよび結果の生成後に次のステップを決定することを可能にする便利なラベルが複数付けられます。
特定のスイートに属するチェックを一覧表示します。
$ oc get compliancecheckresults -l compliance.openshift.io/suite=example-compliancesuite
特定のスキャンに属するチェックを一覧表示します。
$ oc get compliancecheckresults -l compliance.openshift.io/scan=example-compliancescan
すべての ComplianceCheckResult
オブジェクトが ComplianceRemediation
オブジェクトを作成する訳ではありません。自動的に修復できる ComplianceCheckResult
オブジェクトのみになります。ComplianceCheckResult
オブジェクトには、compliance.openshift.io/automated-remediation
ラベルでラベル付けされる場合に関連する修復が含まれます。修復の名前はチェックの名前と同じです。
自動的に修復できる障害のあるチェックをすべて一覧表示します。
$ oc get compliancecheckresults -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'
手動で修復する必要のある障害のあるチェックをすべて一覧表示します。
$ oc get 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.9.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
オブジェクトなど) 異なる種類のオブジェクトになりますが、通常は修復を適用については管理者が判断します。そうでない場合には、コンプライアンス 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.9.3. カスタマイズされたマシン設定プールを使用するときに修復を適用する
カスタム MachineConfigPool
を作成するときは、MachineConfigPool
にラベルを追加して、KubeletConfig
に存在する machineConfigPoolSelector
がそのラベルを MachineConfigPool
と一致させることができるようにします。
コンプライアンス Operator が修復の適用を終了した後に、MachineConfigPool
オブジェクトが予期せず一時停止を解除できない可能性があるため、KubeletConfig
ファイルでは、protectKernelDefaults:false
を設定しないでください。
手順
ノードを一覧表示します。
$ oc get nodes
出力例
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 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.9.4. 修復の適用
ブール値の属性 spec.apply
は、コンプライアンス Operator で修復を適用するかどうかを制御します。属性を true
に設定すると、修復を適用することができます。
$ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects --patch '{"spec":{"apply":true}}' --type=merge
コンプライアンス 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
に設定してマシン設定プールを一時停止できます。
コンプライアンス Operator は修復を自動的に適用できます。ScanSetting
の最上位のオブジェクトに autoApplyRemediations: true
を設定します。
修復の自動敵に適用するかどうかについては、慎重に考慮する必要があります。
5.9.5. プラットフォームチェックの手動による修復
通常、プラットフォームスキャンをチェックする場合、以下の 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 annotate compliancescans/<scan_name> compliance.openshift.io/rescan=
5.9.6. 修復の更新
新しいバージョンのコンプライアンスコンテンツが使用されると、以前のバージョンとは異なる新しいバージョンの修復が提供される可能性があります。コンプライアンス Operator は、適用される修復の以前のバージョンを保持します。OpenShift Container Platform の管理者は、確認し、適用する新規バージョンについても通知されます。以前に適用されたものの、更新された ComplianceRemediation オブジェクトはそのステータスを Outdated に変更します。古いオブジェクトには簡単に検索できるようにラベルが付けられます。
以前に適用された修復内容は ComplianceRemediation
オブジェクトの spec.outdated
属性に保存され、新規に更新された内容は spec.current
属性に保存されます。コンテンツを新しいバージョンに更新した後に、管理者は修復を確認する必要があります。spec.outdated
属性が存在する限り、これは結果として作成される MachineConfig
オブジェクトをレンダリングするために使用されます。spec.outdated
属性が削除された後に、コンプライアンス Operator は結果として生成される MachineConfig
オブジェクトを再度レンダリングし、これにより Operator は設定をノードにプッシュします。
手順
古い修復について検索します。
$ oc get complianceremediations -lcomplianceoperator.openshift.io/outdated-remediation=
出力例
NAME STATE workers-scan-no-empty-passwords Outdated
現在適用されている修復は
Outdated
属性に保存され、新規の、適用されていない修復はCurrent
属性に保存されます。新規バージョンに問題がなれば、Outdated
フィールドを削除します。更新された内容を保持する必要がある場合には、Current
およびOutdated
属性を削除します。修復の新しいバージョンを適用します。
$ oc patch complianceremediations workers-scan-no-empty-passwords --type json -p '[{"op":"remove", "path":/spec/outdated}]'
修復の状態は、
Outdated
からApplied
に切り替わります。$ oc get complianceremediations workers-scan-no-empty-passwords
出力例
NAME STATE workers-scan-no-empty-passwords Applied
- ノードは新規の修復バージョンを適用し、再起動します。
5.9.7. 修復の適用解除
以前に適用された修復を適用解除することが必要になる場合があります。
手順
apply
フラグをfalse
に設定します。$ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects -p '{"spec":{"apply":false}}' --type=merge
修復ステータスは
NotApplied
に変更され、複合のMachineConfig
オブジェクトは修復を含まないように再度レンダリングされます。重要修復を含む影響を受けるすべてのノードが再起動されます。
5.9.8. 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 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 patch complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -p '{"spec":{"apply":false}}' --type=merge
scan-name
を使用して、修復が適用されたKubeletConfig
オブジェクトを見つけます。$ oc 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 KubeletConfig compliance-operator-kubelet-master
重要修復を含む影響を受けるすべてのノードが再起動されます。
また、修正を自動適用する調整済みプロファイルのスケジュールされたスキャンからルールを除外する必要があります。除外しない場合、修正は次のスケジュールされたスキャン中に再適用されます。
5.9.9. 一貫性のない ComplianceScan
ScanSetting
オブジェクトは、ScanSetting
または ScanSettingBinding
オブジェクトから生成されるコンプライアンススキャンがスキャンするノードロールを一覧表示します。通常、各ノードのロールはマシン設定プールにマップされます。
マシン設定プールのすべてのマシンが同一であり、プールのノードからのすべてのスキャン結果が同一であることが予想されます。
一部の結果が他とは異なる場合、コンプライアンス Operator は一部のノードが INCONSISTENT
として報告される ComplianceCheckResult
オブジェクトにフラグを付けます。すべての ComplianceCheckResult
オブジェクトには、compliance.openshift.io/inconsistent-check
のラベルも付けられます。
プール内のマシン数は非常に大きくなる可能性があるため、コンプライアンス 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 annotate compliancescans/<scan_name> compliance.openshift.io/rescan=