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 というキーが含まれる必要があり、このキーの値はテーラリングのコンテンツです。

手順

  1. ファイルから ConfigMap オブジェクトを作成します。

    $ oc create configmap <scan_name> --from-file=tailoring.xml=/path/to/the/tailoringFile.xml
  2. スイートに属するスキャンでテーラリングファイルを参照します。

    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 フラグを設定し、修復を自動的に更新します。