5.10. 高度なコンプライアンス Operator タスクの実行
コンプライアンス Operator には、デバッグや既存のツールとの統合を目的とする上級ユーザー向けのオプションが含まれます。
5.10.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: quay.io/complianceascode/ocp4:latest 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.10.2. 未加工の調整済みプロファイルの使用
TailoredProfile
CR は最も一般的なテーラリング操作を有効にする一方で、XCCDF 標準は OpenSCAP プロファイルの調整におけるより多くの柔軟性を提供します。さらに、組織が以前に OpenScap を使用していた場合、既存の XCCDF テーラリングファイルが存在し、これを再利用できる可能性があります。
ComplianceSuite
オブジェクトには、カスタムのテーラリングファイルにポイントできるオプションの TailoringConfigMap
属性が含まれます。TailoringConfigMap
属性の値は設定マップの名前です。これには、tailoring.xml
というキーが含まれる必要があり、このキーの値はテーラリングのコンテンツです。
手順
ファイルから
ConfigMap
オブジェクトを作成します。$ oc create configmap <scan_name> --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: quay.io/complianceascode/ocp4:latest debug: true tailoringConfigMap: name: <scan_name> nodeSelector: node-role.kubernetes.io/worker: ""
5.10.3. 再スキャンの実行
通常、毎週月曜日または日次など、定義されたスケジュールでスキャンを再実行する必要がある場合があります。また、ノードの問題を修正した後にスキャンを 1 回再実行することは役に立ちます。単一スキャンを実行するには、スキャンに compliance.openshift.io/rescan=
オプションでアノテーションを付けます。
$ oc annotate compliancescans/<scan_name> 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.10.4. 結果についてのカスタムストレージサイズの設定
ComplianceCheckResult
などのカスタムリソースは、スキャンされたすべてのノード間での単一チェックの集計された結果を表しますが、スキャナーによって生成される未加工の結果を確認することが役に立つ場合もあります。未加工の結果は ARF 形式で生成され、サイズが大きくなる可能性がありますが (ノードあたり数十メガバイト)、それらを etcd
のキーと値のストアでサポートされる Kubernetes リソースに保存することは実際的ではありません。すべてのスキャンは、1GB のサイズにデフォルト設定される永続ボリューム (PV) を作成します。環境によっては、PV サイズを適宜増やす必要がある場合があります。これは、ScanSetting
および ComplianceScan
リソースの両方に公開される rawResultStorage.size
属性を使用して実行されます。
関連するパラメーターは rawResultStorage.rotation
であり、これは古いスキャンのローテーションが行われる前に保持されるスキャンの数を制御します。デフォルト値は 3 です。ローテーションポリシーを 0 に設定するとローテーションは無効になります。デフォルトのローテーションポリシーと、未加工の ARF スキャンレポートにつき 100 MB を見積もり、お使いの環境に適した PV サイズを計算できます。
5.10.4.1. カスタム結果ストレージ値の使用
OpenShift Container Platform は各種のパブリッククラウドまたはベアメタルにデプロイできるので、コンプライアンス Operator は利用可能なストレージ設定を判別できません。デフォルトで、コンプライアンス 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.10.5. スイートスキャンによって生成される修復の適用
ComplianceSuite
オブジェクトで autoApplyRemediations
ブール値パラメーターを使用することもできますが、オブジェクトに compliance.openshift.io/apply-remediations
のアノテーションを付けることもできます。これにより、Operator は作成されるすべての修復を適用できます。
手順
-
以下を実行して、
compliance.openshift.io/apply-remediations
アノテーションを適用します。
$ oc annotate compliancesuites/<suite-_name> compliance.openshift.io/apply-remediations=
5.10.6. 修復の自動更新
新しいコンテンツを含むスキャンは、修復に OUTDATED
というマークを付ける可能性があります。管理者は、compliance.openshift.io/remove-outdated
アノテーションを適用して新規の修復を適用し、古い修復を削除できます。
手順
-
compliance.openshift.io/remove-outdated
アノテーションを適用します。
$ oc annotate compliancesuites/<suite_name> compliance.openshift.io/remove-outdated=
または、ScanSetting
または ComplianceSuite
オブジェクトに autoUpdateRemediations
フラグを設定し、修復を自動的に更新します。
5.10.7. コンプライアンスオペレーター向けのカスタム 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 - secret
SCC を作成します。
$ oc create -f restricted-adjusted-compliance.yaml
出力例
securitycontextconstraints.security.openshift.io/restricted-adjusted-compliance created
検証
SCC が作成されたことを確認します。
$ oc get 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"]