5.12. コンプライアンス Operator のトラブルシューティング
このセクションでは、コンプライアンス Operator のトラブルシューティングの方法について説明します。この情報は、問題を診断したり、バグレポートに情報を提供したりする際に役立ちます。一般的なヒントには、以下が含まれます。
コンプライアンス Operator は、重要なことが発生すると Kubernetes イベントを生成します。コマンドを使用して、クラスター内のすべてのイベントを表示できます。
$ oc get events -n openshift-compliance
または、コマンドを使用してスキャンなどのオブジェクトのイベントを表示します。
$ oc describe -n openshift-compliance compliancescan/cis-compliance
コンプライアンス Operator は複数のコントローラーで設定されており、API オブジェクトごとに約 1 つのコントローラーで設定されます。問題のある API オブジェクトに対応するコントローラーのみをフィルターすることが役に立つ場合があります。
ComplianceRemediation
を適用できない場合、remediationctrl
コントローラーのメッセージを表示します。jq
で解析することにより、単一のコントローラーからのメッセージをフィルターできます。$ oc -n openshift-compliance logs compliance-operator-775d7bddbd-gj58f \ | jq -c 'select(.logger == "profilebundlectrl")'
タイムスタンプについては、UTC の UNIX エポックからの経過時間で秒単位でログに記録されます。人間が判読可能な日付に変換するには、
date -d @timestamp --utc
を使用します。以下は例になります。$ date -d @1596184628.955853 --utc
-
数多くのカスタムリソースで、最も重要な
ComplianceSuite
およびScanSetting
でdebug
オプションを設定できます。このオプションを有効にすると、OpenSCAP スキャナー Pod や他のヘルパー Pod の詳細度が上がります。 -
単一ルールの合否が予期せずに出される場合、そのルールのみを使用して単一スキャンまたはスイートを実行し、対応する
ComplianceCheckResult
オブジェクトからルール ID を見つけ、それをScan
CR のrule
属性として使用することが役に立つ場合があります。次に、debug
オプションが有効になると、スキャナー Pod のscanner
コンテナーログに未加工の OpenSCAP ログが表示されます。
5.12.1. スキャンの仕組み
以下のセクションでは、コンプライアンス Operator スキャンのコンポーネントおよびステージについて説明します。
5.12.1.1. コンプライアンスのソース
コンプライアンスコンテンツは、ProfileBundle
オブジェクトから生成される Profile
オブジェクトに保存されます。コンプライアンス Operator は、ProfileBundle
をクラスター用とクラスターノード用に作成します。
$ oc get -n openshift-compliance profilebundle.compliance
$ oc get -n openshift-compliance profile.compliance
ProfileBundle
オブジェクトは、 Bundle
の名前でラベルが付けられたデプロイメントで処理されます。Bundle
で問題のトラブルシューティングを行うには、デプロイメントを見つけ、デプロイメントで Pod のログを表示できます。
$ oc logs -n openshift-compliance -lprofile-bundle=ocp4 -c profileparser
$ oc get -n openshift-compliance deployments,pods -lprofile-bundle=ocp4
$ oc logs -n openshift-compliance pods/<pod-name>
$ oc describe -n openshift-compliance pod/<pod-name> -c profileparser
5.12.1.2. ScanSetting および ScanSettingBinding のライフサイクルおよびデバッグ
有効なコンプライアンスコンテンツソースを使用して、高レベルの ScanSetting
および ScanSettingBinding
オブジェクトを、ComplianceSuite
および ComplianceScan
オブジェクトを生成するために使用できます。
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: my-companys-constraints debug: true # For each role, a separate scan will be created pointing # to a node-role specified in roles roles: - worker --- apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: my-companys-compliance-requirements profiles: # Node checks - name: rhcos4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 # Cluster checks - name: ocp4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: my-companys-constraints kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1
ScanSetting
および ScanSettingBinding
オブジェクトはどちらも、 logger=scansettingbindingctrl
のタグの付けられた同じコントローラーで処理されます。これらのオブジェクトにはステータスがありません。問題はイベントの形式で通信されます。
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuiteCreated 9m52s scansettingbindingctrl ComplianceSuite openshift-compliance/my-companys-compliance-requirements created
今回のリリースにより、ComplianceSuite
オブジェクトが作成されました。フローは新規に作成された ComplianceSuite
を継続して調整します。
5.12.1.3. ComplianceSuite カスタムリソースのライフサイクルおよびデバッグ
ComplianceSuite
CR は ComplianceScan
CR に関連したラッパーです。ComplianceSuite
CR は、 logger=suitectrl
のタグが付けられたコントローラーによって処理されます。このコントローラーは、スイートからのスキャンの作成を処理し、個別のスキャンのステータスを調整し、これを単一の Suite ステータスに集約します。スイートが定期的に実行するよう設定されている場合、suitectrl
は、初回の実行後にスキャンをスイートで再実行する CronJob
CR の作成にも対応します。
$ oc get cronjobs
出力例
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE <cron_name> 0 1 * * * False 0 <none> 151m
最も重要な問題について、イベントが生成されます。oc describe compliancesuites/<name>
を使用してそれらを表示します。Suite
オブジェクトには、 Status
サブリソースも含まれており、これはこのスイートに属する Scan
オブジェクトが Status
サブリソースを更新すると更新されます。予想されるすべてのスキャンが作成されると、コントローラーがスキャンコントローラーに渡されます。
5.12.1.4. ComplianceScan カスタムリソースのライフサイクルおよびデバッグ
ComplianceScan
CR は scanctrl
コントローラーによって処理されます。これは、実際のスキャンとスキャン結果が作成される場所でもあります。それぞれのスキャンは複数のフェーズを経由します。
5.12.1.4.1. Pending (保留) フェーズ
このフェーズでは、スキャンがその正確性について検証されます。ストレージサイズなどの一部のパラメーターが無効な場合、スキャンは ERROR 結果と共に DONE に移行します。それ以外の場合は、Launching (起動) フェーズに進みます。
5.12.1.4.2. Launching (起動) フェーズ
このフェーズでは、いくつかの設定マップにスキャナー Pod の環境またはスキャナー Pod が評価するスクリプトが直接含まれます。設定マップを一覧表示します。
$ oc -n openshift-compliance get cm \ -l compliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=
これらの設定マップはスキャナー Pod によって使用されます。スキャナーの動作を変更したり、スキャナーのデバッグレベルを変更したり、未加工の結果を出力したりする必要がある場合は、1 つの方法として設定マップを変更することができます。その後、未加工の ARF の結果を保存するために永続ボリューム要求 (PVC) がスキャンごとに作成されます。
$ oc get pvc -n openshift-compliance -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
PVC はスキャンごとの ResultServer
デプロイメントでマウントされます。ResultServer
は、個別のスキャナー Pod が完全な ARF 結果をアップロードする単純な HTTP サーバーです。各サーバーは、異なるノードで実行できます。完全な ARF の結果のサイズは非常に大きくなる可能性があり、複数のノードから同時にマウントできるボリュームを作成することができると想定することはできません。スキャンが終了した後に、ResultServer
デプロイメントはスケールダウンされます。未加工の結果のある PVC は別のカスタム Pod からマウントでき、結果はフェッチしたり、検査したりできます。スキャナー Pod と ResultServer
間のトラフィックは相互 TLS プロトコルで保護されます。
最後に、スキャナー Pod はこのフェーズで起動します。Platform
スキャンインスタンスの 1 つのスキャナー Pod と、node
スキャンインスタンスの一致するノードごとに 1 つのスキャナー Pod です。ノードごとの Pod にはノード名のラベルが付けられます。それぞれの Pod には、常に ComplianceScan
という名前のラベルが付けられます。
$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels
出力例
NAME READY STATUS RESTARTS AGE LABELS rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod 0/2 Completed 0 39m compliance.openshift.io/scan-name=rhcos4-e8-worker,targetNode=ip-10-0-169-90.eu-north-1.compute.internal,workload=scanner
+ スキャンは Running (実行) フェーズに進みます。
5.12.1.4.3. Running (実行) フェーズ
実行フェーズは、スキャナー Pod の完了後に開始します。以下の用語およびプロセスは実行フェーズで使用されます。
-
init container:
content-container
という 1 つの init コンテナーがあります。これは、contentImage コンテナーを実行し、contentFile を、この Pod の他のコンテナーで共有される/content
ディレクトリーにコピーします。 -
scanner: このコンテナーはスキャンを実行します。ノードのスキャンの場合には、コンテナーはノードファイルシステムを
/host
としてマウントし、init コンテナーによって配信されるコンテンツをマウントします。また、コンテナーは Launching (起動) フェーズで作成されるentrypoint
ConfigMap
をマウントし、これを実行します。エントリーポイントConfigMap
のデフォルトスクリプトは OpenSCAP を実行し、結果ファイルを Pod のコンテナー間で共有される/results
ディレクトリーに保存します。この Pod のログを表示して、OpenSCAP スキャナーがチェックした内容を判別できます。より詳細な出力は、debug
フラグを使用して表示できます。 logcollector: logcollector コンテナーは、スキャナーコンテナーが終了するまで待機します。その後、これは
ConfigMap
として完全な ARF 結果をResultServer
にアップロードし、スキャン結果および OpenSCAP 結果コードと共に XCCDF 結果を個別にアップロードします。これらの結果の Config Map には、スキャン名 (compliance.openshift.io/scan-name=rhcos4-e8-worker
) のラベルが付けられます。$ oc describe cm/rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod
出力例
Name: rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod Namespace: openshift-compliance Labels: compliance.openshift.io/scan-name-scan=rhcos4-e8-worker complianceoperator.openshift.io/scan-result= Annotations: compliance-remediations/processed: compliance.openshift.io/scan-error-msg: compliance.openshift.io/scan-result: NON-COMPLIANT OpenSCAP-scan-result/node: ip-10-0-169-90.eu-north-1.compute.internal Data ==== exit-code: ---- 2 results: ---- <?xml version="1.0" encoding="UTF-8"?> ...
Platform
スキャンのスキャナー Pod も同様ですが、以下の点で異なります。
-
api-resource-collector
という追加の init コンテナーがあります。これは content-container init、コンテナーで提供される OpenSCAP コンテンツを読み取り、コンテンツで確認する必要のある API リソースを判別し、それらの API リソースをscanner
コンテナーが読み取りを行う共有ディレクトリーに保存します。 -
scanner
コンテナーは、ホストファイルシステムをマウントする必要はありません。
スキャナー Pod が実行されると、スキャンは Aggregating (集計) フェーズに移行します。
5.12.1.4.4. Aggregating (集計) フェーズ
Aggregating (集計) フェーズでは、スキャンコントローラーがアグリゲーター Pod と呼ばれる別の Pod を起動します。その目的は、結果の ConfigMap
オブジェクトを取り、結果を読み取り、それぞれのチェックの結果について対応する Kubernetes オブジェクトを作成することにあります。チェックの失敗を自動的に修復できる場合は、 ComplianceRemediation
オブジェクトが作成されます。チェックと修復についての人間が判読できるメタデータを提供するために、アグリゲーター Pod は init コンテナーを使用して OpenSCAP コンテンツもマウントします。
設定マップがアグリゲーター Pod によって処理される場合、これには compliance-remediations/processed
ラベルでラベルが付けられます。このフェーズの結果は ComplianceCheckResult
オブジェクトになります。
$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
出力例
NAME STATUS SEVERITY rhcos4-e8-worker-accounts-no-uid-except-zero PASS high rhcos4-e8-worker-audit-rules-dac-modification-chmod FAIL medium
ComplianceRemediation
オブジェクト:
$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
出力例
NAME STATE rhcos4-e8-worker-audit-rules-dac-modification-chmod NotApplied rhcos4-e8-worker-audit-rules-dac-modification-chown NotApplied rhcos4-e8-worker-audit-rules-execution-chcon NotApplied rhcos4-e8-worker-audit-rules-execution-restorecon NotApplied rhcos4-e8-worker-audit-rules-execution-semanage NotApplied rhcos4-e8-worker-audit-rules-execution-setfiles NotApplied
これらの CR が作成されると、アグリゲーター Pod は終了し、スキャンは Done (終了) フェーズに移行します。
5.12.1.4.5. Done (終了) フェーズ
最終のスキャンフェーズでは、必要な場合にスキャンリソースがクリーンアップされ、ResultServer
デプロイメントは (スキャンが 1 回限りの場合) スケールダウンされるか、または (スキャンが継続される場合) 削除されます。次回のスキャンインスタンスではデプロイメントを再作成します。
また、Done (終了) フェーズでは、スキャンにアノテーションを付けてスキャンの再実行をトリガーすることもできます。
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
スキャンが Done (終了) フェーズに到達した後に、修復が autoApplyRemediations: true
を指定して自動的に適用されるように設定されていない限り、自動的に実行されることは何もありません。OpenShift Container Platform 管理者は、修復を確認し、必要に応じてそれらを適用できるようになりました。修復が自動的に適用されるように設定されている場合、ComplianceSuite
コントローラーが Done (終了) フェーズで引き継ぎ、マシン設定プールをスキャンがマップされるポイントで一時停止し、すべての修復を 1 回で適用します。修復が適用されると、ComplianceRemediation
コントローラーが引き継ぎます。
5.12.1.5. ComplianceRemediation コントローラーのライフサイクルおよびデバッグ
サンプルスキャンは特定の結果を報告します。修復の 1 つを有効にするには、apply
属性を true
に切り替えます。
$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge
ComplianceRemediation
コントローラー (logger=remediationctrl
) は変更されたオブジェクトを調整します。調整の結果として、調整される修復オブジェクトのステータスが変更されますが、適用されたすべての修復が含まれる、レンダリングされるスイートごとの MachineConfig
オブジェクトも変更されます。
MachineConfig
オブジェトは常に 75-
で開始し、スキャンとスィートに基づいて名前が付けられます。
$ oc get mc | grep 75-
出力例
75-rhcos4-e8-worker-my-companys-compliance-requirements 3.2.0 2m46s
mc
を現在設定している修復はマシン設定のアノテーションに一覧表示されます。
$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements
出力例
Name: 75-rhcos4-e8-worker-my-companys-compliance-requirements Labels: machineconfiguration.openshift.io/role=worker Annotations: remediation/rhcos4-e8-worker-audit-rules-dac-modification-chmod:
ComplianceRemediation
コントローラーのアルゴリズムは以下のようになります。
- 現在適用されているすべての修復は初期の修復セットに読み込まれます。
- 調整された修復が適用されることが予想される場合、それはセットに追加されます。
-
MachineConfig
オブジェクトはセットからレンダリングされ、セット内の修復の名前でアノテーションが付けられます。セットが空の場合 (最後の修復は適用されない)、レンダリングされるMachineConfig
オブジェクトは削除されます。 - レンダリングされたマシン設定がクラスターにすでに適用されているものとは異なる場合にのみ、適用される MC は更新されます (または作成されるか、削除されます)。
-
MachineConfig
オブジェクトの作成または変更により、machineconfiguration.openshift.io/role
ラベルに一致するノードの再起動がトリガーされます。詳細は、Machine Config Operator のドキュメントを参照してください。
修復ループは、レンダリングされたマシン設定が更新され (必要な場合)、調整された修復オブジェクトのステータスが更新されると終了します。この場合、修復を適用すると再起動がトリガーされます。再起動後、スキャンにアノテーションを付け、再度実行します。
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
スキャンが実行され、終了します。渡される修復の有無を確認します。
$ oc -n openshift-compliance \ get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod
出力例
NAME STATUS SEVERITY rhcos4-e8-worker-audit-rules-dac-modification-chmod PASS medium
5.12.1.6. 役に立つラベル
コンプライアンス Operator によって起動する各 Pod には、それが属するスキャンおよびその機能にとくに関連するラベルが付けられます。スキャン ID には compliance.openshift.io/scan-name
ラベルが付けられます。ワークロード ID には、workload
ラベルでラベルが付けられます。
コンプライアンス Operator は以下のワークロードをスケジュールします。
- scanner: コンプライアンススキャンを実行します。
- resultserver: コンプライアンススキャンの未加工の結果を保存します。
- aggregator: 結果を集計し、不整合を検出し、結果オブジェクト (チェックの結果と修復) を出力します。
- suitererunner: 再実行するスイートにタグを付けます (スケジュールが設定されている場合)。
- profileparser: データストリームを解析し、適切なプロファイル、ルールおよび変数を作成します。
デバッグおよびログが特定のワークロードに必要な場合は、以下を実行します。
$ oc logs -l workload=<workload_name> -c <container_name>
5.12.2. コンプライアンス Operator のリソース制限の増加
コンプライアンス Operator は、デフォルトの制限よりもメモリーを多く必要とする場合があります。この問題を軽減する最善の方法は、カスタムリソースの制限を設定することです。
スキャナー Pod のデフォルトのメモリーおよび CPU 制限を増やすには、ScanSetting カスタムリソース を参照してください。
手順
Operator のメモリー制限を 500 Mi に増やすには、
co-memlimit-patch.yaml
という名前の以下のパッチファイルを作成します。spec: config: resources: limits: memory: 500Mi
パッチファイルを適用します。
$ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge
5.12.3. Operator リソース制約の設定
resources
フィールドは、Operator Lifecycle Manager (OLM) によって作成される Pod 内のすべてのコンテナーの Resource Constraints を定義します。
このプロセスで適用されるリソース制約は、既存のリソース制約を上書きします。
手順
Subscription
オブジェクトを編集して、各コンテナーに 0.25 cpu と 64 Mi のメモリーの要求と、0.5 cpu と 128 Mi のメモリーの制限を挿入します。kind: Subscription metadata: name: custom-operator spec: package: etcd channel: alpha config: resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
5.12.4. ScanSetting タイムアウトの設定
ScanSetting
オブジェクトには、ComplianceScanSetting
オブジェクトで 1h30m
などの期間文字列として指定できるタイムアウトオプションがあります。指定されたタイムアウト内にスキャンが終了しない場合、スキャンは maxRetryOnTimeout
制限に達するまで再試行されます。
手順
ScanSetting で
timeout
とmaxRetryOnTimeout
を設定するには、既存のScanSetting
オブジェクトを変更します。apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: rotation: 3 size: 1Gi roles: - worker - master scanTolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists schedule: '0 1 * * *' timeout: '10m0s' 1 maxRetryOnTimeout: 3 2
5.12.5. サポート
本書で説明されている手順、または OpenShift Container Platform で問題が発生した場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルでは、次のことができます。
- Red Hat 製品に関するアーティクルおよびソリューションを対象とした Red Hat ナレッジベースの検索またはブラウズ。
- Red Hat サポートに対するサポートケースの送信。
- その他の製品ドキュメントへのアクセス。
クラスターの問題を特定するには、OpenShift Cluster Manager で Insights を使用できます。Insights により、問題の詳細と、利用可能な場合は問題の解決方法に関する情報が提供されます。
本書の改善への提案がある場合、またはエラーを見つけた場合は、最も関連性の高いドキュメントコンポーネントの Jira Issue を送信してください。セクション名や OpenShift Container Platform バージョンなどの具体的な情報を提供してください。