5.11. 高度なCompliance Operator タスクの実行
Compliance Operator には、デバッグや既存のツールとの統合を目的とする上級ユーザー向けのオプションが含まれます。
5.11.1. ComplianceSuite オブジェクトおよび ComplianceScan オブジェクトの直接使用
ユーザーは ScanSetting および ScanSettingBinding オブジェクトを利用してスイートおよびスキャンを定義することが推奨されますが、 ComplianceSuite オブジェクトを直接定義する有効なユースケースもあります。
-
スキャンする単一ルールのみを指定する。これは、デバッグモードが非常に詳細な情報を取得する可能性があるため、
debug: true属性を使用してデバッグする際に役立ちます。これにより、OpenSCAP スキャナーの詳細度が上がります。テストを 1 つのルールに制限すると、デバッグ情報の量を減らすことができます。 - カスタム nodeSelector を指定する。修復を適用可能にするには、nodeSelector はプールと一致する必要があります。
- テーラリングファイルでスキャンをカスタム設定マップをポイントする。
- テストまたは開発目的の場合で、バンドルからのプロファイルの解析に伴うオーバーヘッドが不要な場合。
以下の例は、単一のルールのみでワーカーマシンをスキャンする ComplianceSuite を示しています。
apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
name: workers-compliancesuite
spec:
scans:
- name: workers-scan
profile: xccdf_org.ssgproject.content_profile_moderate
content: ssg-rhcos4-ds.xml
contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc...
debug: true
rule: xccdf_org.ssgproject.content_rule_no_direct_root_logins
nodeSelector:
node-role.kubernetes.io/worker: ""
上記の ComplianceSuite オブジェクトおよび ComplianceScan オブジェクトは、OpenSCAP が想定する形式で複数の属性を指定します。
プロファイル、コンテンツ、またはルールの値を見つけるには、最初に ScanSetting および ScanSettingBinding から同様の Suite を作成して開始するか、ルールやプロファイルなどの ProfileBundle オブジェクトから解析されたオブジェクトを検査することができます。これらのオブジェクトには、ComplianceSuite から参照するために使用できる xccdf_org 識別子が含まれます。
5.11.2. ScanSetting スキャンの PriorityClass の設定
大規模な環境では、デフォルトの PriorityClass オブジェクトの優先順位が低すぎて、Pod が時間どおりにスキャンを実行することを保証できない場合があります。コンプライアンスを維持するか、自動スキャンを保証する必要のあるクラスターの場合、PriorityClass 変数を設定して、Compliance Operator がリソースの制約の状況で常に優先順位が指定されるようにします。
手順
PriorityClass変数を設定します。apiVersion: compliance.openshift.io/v1alpha1 strictNodeScan: true metadata: name: default namespace: openshift-compliance priorityClass: compliance-high-priority 1 kind: ScanSetting showNotApplicable: false rawResultStorage: nodeSelector: node-role.kubernetes.io/master: '' pvAccessModes: - 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 tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoSchedule key: node.kubernetes.io/memory-pressure operator: Exists schedule: 0 1 * * * roles: - master - worker scanTolerations: - operator: Exists- 1
ScanSettingで参照されるPriorityClassが見つからない場合、Operator はPriorityClassを空のままで警告を発行し、PriorityClassなしでスキャンのスケジュールを続行します。
5.11.3. 未加工の調整済みプロファイルの使用
TailoredProfile CR は最も一般的なテーラリング操作を有効にする一方で、XCCDF 標準は OpenSCAP プロファイルの調整におけるより多くの柔軟性を提供します。さらに、組織が以前に OpenScap を使用していた場合、既存の XCCDF テーラリングファイルが存在し、これを再利用できる可能性があります。
ComplianceSuite オブジェクトには、カスタムのテーラリングファイルにポイントできるオプションの TailoringConfigMap 属性が含まれます。TailoringConfigMap 属性の値は設定マップの名前です。これには、tailoring.xml というキーが含まれる必要があり、このキーの値はテーラリングのコンテンツです。
手順
ファイルから
ConfigMapオブジェクトを作成します。$ oc -n openshift-compliance \ create configmap nist-moderate-modified \ --from-file=tailoring.xml=/path/to/the/tailoringFile.xml
スイートに属するスキャンでテーラリングファイルを参照します。
apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceSuite metadata: name: workers-compliancesuite spec: debug: true scans: - name: workers-scan profile: xccdf_org.ssgproject.content_profile_moderate content: ssg-rhcos4-ds.xml contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc... debug: true tailoringConfigMap: name: nist-moderate-modified nodeSelector: node-role.kubernetes.io/worker: ""
5.11.4. 再スキャンの実行
通常、毎週月曜日または日次など、定義されたスケジュールでスキャンを再実行する必要がある場合があります。また、ノードの問題を修正した後にスキャンを 1 回再実行することは役に立ちます。単一スキャンを実行するには、スキャンに compliance.openshift.io/rescan= オプションでアノテーションを付けます。
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
再スキャンにより、rhcos-moderate プロファイルの 4 つの追加 mc が生成されます。
$ oc get mc
出力例
75-worker-scan-chronyd-or-ntpd-specify-remote-server 75-worker-scan-configure-usbguard-auditbackend 75-worker-scan-service-usbguard-enabled 75-worker-scan-usbguard-allow-hid-and-hub
スキャン設定の default-auto-apply ラベルが適用されると、修復は自動的に適用され、古い修復が自動的に更新されます。依存関係により適用されなかった修復や、古くなった修復がある場合には、再スキャンにより修復が適用され、再起動がトリガーされる可能性があります。MachineConfig オブジェクトを使用する修復のみが再起動をトリガーします。適用する更新または依存関係がない場合は、再起動は発生しません。
5.11.5. 結果についてのカスタムストレージサイズの設定
ComplianceCheckResult などのカスタムリソースは、スキャンされたすべてのノード間での単一チェックの集計された結果を表しますが、スキャナーによって生成される未加工の結果を確認することが役に立つ場合もあります。未加工の結果は ARF 形式で生成され、サイズが大きくなる可能性がありますが (ノードあたり数十メガバイト)、それらを etcd のキーと値のストアでサポートされる Kubernetes リソースに保存することは実際的ではありません。すべてのスキャンは、1GB のサイズにデフォルト設定される永続ボリューム (PV) を作成します。環境によっては、PV サイズを適宜増やす必要がある場合があります。これは、ScanSetting および ComplianceScan リソースの両方に公開される rawResultStorage.size 属性を使用して実行されます。
関連するパラメーターは rawResultStorage.rotation であり、これは古いスキャンのローテーションが行われる前に保持されるスキャンの数を制御します。デフォルト値は 3 です。ローテーションポリシーを 0 に設定するとローテーションは無効になります。デフォルトのローテーションポリシーと、未加工の ARF スキャンレポートにつき 100 MB を見積もり、お使いの環境に適した PV サイズを計算できます。
5.11.5.1. カスタム結果ストレージ値の使用
OpenShift Container Platform は各種のパブリッククラウドまたはベアメタルにデプロイできるので、Compliance Operator は利用可能なストレージ設定を判別できません。デフォルトで、Compliance Operator はクラスターのデフォルトのストレージクラスを使用して結果を保存するために PV の作成を試行しますが、カスタムストレージクラスは rawResultStorage.StorageClassName 属性を使用して設定できます。
クラスターがデフォルトのストレージクラスを指定しない場合、この属性を設定する必要があります。
標準ストレージクラスを使用するように ScanSetting カスタムリソースを設定し、サイズが 10GB の永続ボリュームを作成し、最後の 10 件の結果を保持します。
ScanSetting CR の例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: storageClassName: standard rotation: 10 size: 10Gi roles: - worker - master scanTolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists schedule: '0 1 * * *'
5.11.6. スイートスキャンによって生成される修復の適用
ComplianceSuite オブジェクトで autoApplyRemediations ブール値パラメーターを使用することもできますが、オブジェクトに compliance.openshift.io/apply-remediations のアノテーションを付けることもできます。これにより、Operator は作成されるすべての修復を適用できます。
手順
-
以下を実行して、
compliance.openshift.io/apply-remediationsアノテーションを適用します。
$ oc -n openshift-compliance \ annotate compliancesuites/workers-compliancesuite compliance.openshift.io/apply-remediations=
5.11.7. 修復の自動更新
新しいコンテンツを含むスキャンは、修復に OUTDATED というマークを付ける可能性があります。管理者は、compliance.openshift.io/remove-outdated アノテーションを適用して新規の修復を適用し、古い修復を削除できます。
手順
-
compliance.openshift.io/remove-outdatedアノテーションを適用します。
$ oc -n openshift-compliance \ annotate compliancesuites/workers-compliancesuite compliance.openshift.io/remove-outdated=
または、ScanSetting または ComplianceSuite オブジェクトに autoUpdateRemediations フラグを設定し、修復を自動的に更新します。
5.11.8. コンプライアンスオペレーター向けのカスタム SCC の作成
一部の環境では、カスタムのセキュリティーコンテキスト制約 (SCC) ファイルを作成して、コンプライアンスオペレーターの api-resource-collector が正しいアクセス許可を利用できるようにする必要があります。
前提条件
-
admin権限がある。
手順
restricted-adjusted-compliance.yamlという名前の YAML ファイルで SCC を定義します。SecurityContextConstraintsオブジェクト定義allowHostDirVolumePlugin: false allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegeEscalation: true allowPrivilegedContainer: false allowedCapabilities: null apiVersion: security.openshift.io/v1 defaultAddCapabilities: null fsGroup: type: MustRunAs kind: SecurityContextConstraints metadata: name: restricted-adjusted-compliance priority: 30 1 readOnlyRootFilesystem: false requiredDropCapabilities: - KILL - SETUID - SETGID - MKNOD runAsUser: type: MustRunAsRange seLinuxContext: type: MustRunAs supplementalGroups: type: RunAsAny users: - system:serviceaccount:openshift-compliance:api-resource-collector 2 volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secretSCC を作成します。
$ oc create -n openshift-compliance -f restricted-adjusted-compliance.yaml
出力例
securitycontextconstraints.security.openshift.io/restricted-adjusted-compliance created
検証
SCC が作成されたことを確認します。
$ oc get -n openshift-compliance scc restricted-adjusted-compliance
出力例
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES restricted-adjusted-compliance false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny 30 false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
